> i think your wrong there anarko, any question about C in here is fine with
> me, even programming questions, as long as the main focus is gba dev!, i
> think questions about the compiler specific gcc compiler for the gba are
> completely on topic and should be discussed, after all, other people here
> might come up againt the same problems and not have any answers!

The question I asked was SPECIFIC to the ARM IMPLEMENTATION of gcc, gas, and
ld for the GBA.

Now to clarify.....

Apparently there are issues declaring local instances of structures.
Example:

typedef struct
{
     int    stuff,it;
}CRAP;

void bar()
{
   CRAP mycrap;  /* mycrap is a bad address...why? */

    mycrap.stuff = 3; /*can't do this because mycrap is BAD*/

/*.....other code*/
};

I would consider this a legitimate issue :).

             Just Me,
                 *SF

Dennis Ranke wrote:
>
> Hmm, I have now implemented AAN DCT and my decoder now takes on a 233Mhz
> StrongARM 2.9cs to decode a 17kb 240x160 Jpeg to 32768 colours with
> ordered dithering. This speed comes quite near to another jpeg
> implemenation on this computer which i believe is quite good optimized.
> When I take only the difference in clock speed into account, it would
> take about 0.4s on gba.
> This is of course somewhat different to your figures, therefore i am
> wondering if you just stated the speed of your dct core or that of
> the complete decoder.

Nope, I meant the entire kaboodle. Though my file format is not a true JPEG
compliant stream, I still feature all the essentials, but no dithering. I
keep quantisation down just sufficiently to make sure we never comprise the
destination colour range after colour space conversion.
As a point of reference regards the speed, the JPEG library that ARM sells
(circa $60,000 iirc) does about 0.55 MegaPixels on a 40Mhz ARM7. On a 200Mhz
StrongArm their decoder rates at 4.0MegaPixels which is roughly 9.6ms for
240x160 image and approx.
I'm guessing my coder clocks in faster than theirs purely down to the
shortcuts I've taken given the target platform display. If I supported the
full range of options, mine would be marginally slower than theirs right
now, but since I don't need to I'm not bothering. Ask yourself do you really
need all that extra fluff?

> My dct core seems to take about 0.3cs for the above picture, which means
> that there is certainly still a lot of room for optimisation in other
> areas...

An 8-point DCT cannot be done in less than 11 multiplies, it is possible to
arrange the computation so that many of the multiplies are simple scalings
of the final outputs.  These multiplies can then be folded into the
multiplications by the JPEG quantization table entries. The AAN method
leaves only 5 multiplies and 29 adds to be done in the DCT itself.

A big boost can be achieved by short circuiting the DCT for any column that
has its AC terms at zero. This occurs at lot more frequently than might be
expected due to quantisation. If the AC term of any column is zero then the
output is equal to the DC coefficient, with scale factor as needed. You'll
find that in typical images half or more of the columns can be handled in
this fashion.

And once you do all that and are sitting back smiling thinking how cool is
this and maybe starting to think that maybe an MPEG player on that wee
little 16Mhz ARM7 wouldn't be so impossible after all, go lookup Fast DCT
'Approximations'. There you'll discover a whole new avenue of DCTs that use
*ZERO* multiplies, just shifts and adds and go very, very, very fast :)

AndyM

i think your wrong there anarko, any question about C in here is fine with
me, even programming questions, as long as the main focus is gba dev!, i
think questions about the compiler specific gcc compiler for the gba are
completely on topic and should be discussed, after all, other people here
might come up againt the same problems and not have any answers!

ok that's it...

-----Original Message-----
From: anarko [mailto:anarko@...]
Sent: 03 October 2000 21:48
To: Martijn Reuvers
Subject: Re[2]: [gbadev] Compiler issues


Hello Martijn,

Tuesday, October 03, 2000, 5:48:14 PM, you wrote:

MR> Maybe "way out of topic" == "i guess i don't know" :)

that is true. i dont know. but i replied at all because
i wanted to redirect the question to people that
both could help him, and to point out that the list
should not be abused for offtopic questions, C is
not a wierd language with no users, and gcc is especially
not a unknown compiler with no users. there are many
users and forums for this kind of questions, this is
just not one of those (or maybe it is, you tell me)

--
Best regards,
  anarko                            anarko@...



unsubscribe: gbadev-unsubscribe@egroups.com

Hello Martijn,

Tuesday, October 03, 2000, 5:48:14 PM, you wrote:

MR> Maybe "way out of topic" == "i guess i don't know" :)

that is true. i dont know. but i replied at all because
i wanted to redirect the question to people that
both could help him, and to point out that the list
should not be abused for offtopic questions, C is
not a wierd language with no users, and gcc is especially
not a unknown compiler with no users. there are many
users and forums for this kind of questions, this is
just not one of those (or maybe it is, you tell me)

--
Best regards,
  anarko                            anarko@...

In message <005701c02d3b$77d14e20$0e5d6dc2@sean>
           "Sean Dunlevy" <sean@...> wrote:

> Hi,
>      That sounds an interesting program. Any chance of letting us look at
> it?
> I did look at a C implementation of the decode, but that was years ago.

I haven't yet decided what to do with the decoder, but i'm considering
releasing it after i have tidied it up a bit and i would also like
to test it on the gba devkit before doing so.
I don't know when we'll get our devkit, though...

--
exoticorn/icebird

In message <EHEOLOLLINEMBNHDJDFLOEDDHEAA.andy@...>
           "Andy Mucho" <andy@...> wrote:

> Go for the AAN DCT.. Using that I'm currently at 0.31 MegaPixels per second
> (about 8fps) using 8:1 compressed images. That's still in a complete C++
> implementation with no assembler yet. I see maybe a marginal increase in the
> DCT core, though the compiler has done a pretty cool job.
> I expect with some hand tweaking to push this to maybe 10fps, and maybe then
> eek some more speed through other optimisations.

Hmm, I have now implemented AAN DCT and my decoder now takes on a 233Mhz
StrongARM 2.9cs to decode a 17kb 240x160 Jpeg to 32768 colours with
ordered dithering. This speed comes quite near to another jpeg implemenation
on this computer which i believe is quite good optimized.
When I take only the difference in clock speed into account, it would
take about 0.4s on gba.
This is of course somewhat different to your figures, therefore i am
wondering if you just stated the speed of your dct core or that of
the complete decoder.
My dct core seems to take about 0.3cs for the above picture, which means
that there is certainly still a lot of room for optimisation in other
areas...

--
exoticorn/icebird

Hi

foo should get declared on the stack, naybe your stack address is pointing
to ROM instead of RAM?

Regards

Mat

----- Original Message -----
From: "Xyrus" <sfreeman@...>
To: <gbadev@egroups.com>
Sent: Tuesday, October 03, 2000 4:39 PM
Subject: [gbadev] Compiler issues


> Hi guys,
>     I seem to be having some issues with the gcc compiler. It doesn't like
> complex structures for some reason. Here's an example of what I'm talking
> about:
>
> typedef struct{
> float stuff;
> int morestuff[5];
> }MYSTUFF;
>
> typedef struct{
> MYSTUFF crap[2];
> float morecrap;
> }CRAPOLA;
>
>
> Now, if I try to use the above inside of a function:
>
> void Trash()
> {
> CRAPOLA foo;
> foo.morecrap = 5;
> }
>
> The code compiles, but it makes foo into a rom address (verified through
the
> debugger). Obviously the code doesn't work :). Now I know that if you
> initialize a variable to a value (a global) or use static, it assigns the
> variable to a rom address, but does the same thing happen with structs? It
> seems that some structs work and others don't. Why?
>
> I think I'll just go back to doing everything in assembly. :)
>
>                 Just Me,
>                     *SF
>
>
>
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>

Maybe "way out of topic" == "i guess i don't know" :)

Gtz
Martijn
http://www.twotribes.com

----- Original Message -----
From: "Joshua Meeds" <dreamer@...>
To: <gbadev@egroups.com>
Sent: Sunday, October 03, 1999 5:45 PM
Subject: Re: [gbadev] Compiler issues


> Um, eh?  How could talking about a GBA compiler compiling something wrong
> be "way out of topic" on a GBA mailing list?
>
> At 05:39 PM 10/3/2000 +0200, you wrote:
> >Hello Xyrus,
> >
> >Tuesday, October 03, 2000, 5:39:19 PM, you wrote:
> >
> >X> Hi guys,
> >X>     I seem to be having some issues with the gcc compiler. It doesn't
like
> >X> complex structures for some reason. Here's an example of what I'm
talking
> >X> about:
> >
> >this is way out of topic, try some gcc related mailing list
> >
> >--
> >Best regards,
> >  anarko                            anarko@...
> >
> >
> >
> >unsubscribe: gbadev-unsubscribe@egroups.com
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>

Um, eh?  How could talking about a GBA compiler compiling something wrong
be "way out of topic" on a GBA mailing list?

At 05:39 PM 10/3/2000 +0200, you wrote:
>Hello Xyrus,
>
>Tuesday, October 03, 2000, 5:39:19 PM, you wrote:
>
>X> Hi guys,
>X>     I seem to be having some issues with the gcc compiler. It doesn't like
>X> complex structures for some reason. Here's an example of what I'm talking
>X> about:
>
>this is way out of topic, try some gcc related mailing list
>
>--
>Best regards,
>  anarko                            anarko@...
>
>
>
>unsubscribe: gbadev-unsubscribe@egroups.com

Hello Xyrus,

Tuesday, October 03, 2000, 5:39:19 PM, you wrote:

X> Hi guys,
X>     I seem to be having some issues with the gcc compiler. It doesn't like
X> complex structures for some reason. Here's an example of what I'm talking
X> about:

this is way out of topic, try some gcc related mailing list

--
Best regards,
  anarko                            anarko@...

Hi guys,
     I seem to be having some issues with the gcc compiler. It doesn't like
complex structures for some reason. Here's an example of what I'm talking
about:

typedef struct{
float stuff;
int morestuff[5];
}MYSTUFF;

typedef struct{
MYSTUFF crap[2];
float morecrap;
}CRAPOLA;


Now, if I try to use the above inside of a function:

void Trash()
{
CRAPOLA foo;
foo.morecrap = 5;
}

The code compiles, but it makes foo into a rom address (verified through the
debugger). Obviously the code doesn't work :). Now I know that if you
initialize a variable to a value (a global) or use static, it assigns the
variable to a rom address, but does the same thing happen with structs? It
seems that some structs work and others don't. Why?

I think I'll just go back to doing everything in assembly. :)

                 Just Me,
                     *SF

Useful to know. So, it should be possible to squeeze a low-rate stream out
of the
thing. I suppose 32KHz is fine considering the DAC & op-amp isn't likely to
be
all that great to start with...


----- Original Message -----
From: "Andy Mucho" <andy@...>
To: <gbadev@egroups.com>
Sent: Tuesday, October 03, 2000 4:18 PM
Subject: RE: [gbadev] image file format


> Sean Dunlevy wrote:
> >
> > Anyone know the MIPS usage of an MP audio stream? I downloaded a DOS
> > compressor/decompressor and it was a total beast of a program. That
> > psycho-acoustic model stuff is really wild...
>
> Expect on the ARM7 architecture a full 48K 128Kbps Layer3 stream to
require
> close to 30MHZ..
> Obviously pretty useless for the GBA's underpowered CPU..
> So just to give you a hint :) 16K mono MP3 takes just over 5MHZ of power.
> The power required for other variations of bitstream and sample rates,
scale
> in a fairly linear fashion.
> AndyM
>
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>

Sean Dunlevy wrote:
>
> Anyone know the MIPS usage of an MP audio stream? I downloaded a DOS
> compressor/decompressor and it was a total beast of a program. That
> psycho-acoustic model stuff is really wild...

Expect on the ARM7 architecture a full 48K 128Kbps Layer3 stream to require
close to 30MHZ..
Obviously pretty useless for the GBA's underpowered CPU..
So just to give you a hint :) 16K mono MP3 takes just over 5MHZ of power.
The power required for other variations of bitstream and sample rates, scale
in a fairly linear fashion.
AndyM

In message <EHEOLOLLINEMBNHDJDFLOEDDHEAA.andy@...>
           "Andy Mucho" <andy@...> wrote:

> Go for the AAN DCT.. Using that I'm currently at 0.31 MegaPixels per second
> (about 8fps) using 8:1 compressed images. That's still in a complete C++
> implementation with no assembler yet. I see maybe a marginal increase in the
> DCT core, though the compiler has done a pretty cool job.
> I expect with some hand tweaking to push this to maybe 10fps, and maybe then
> eek some more speed through other optimisations.

Yes, that's what i will try to implement today. Thanks to you i now also
have some idea about how fast my implementation should get... ;)
Hm, looking at the IJG dct source, this should be quite straightforward
to do for a compiler, so i wouldn't expect much gain by doing it in asm.

--
exoticorn/icebird

Anyone know the MIPS usage of an MP audio stream? I downloaded a DOS
compressor/decompressor and it was a total beast of a program. That
psycho-acoustic model stuff is really wild...

----- Original Message -----
From: "Andy Mucho" <andy@...>
To: <gbadev@egroups.com>
Sent: Tuesday, October 03, 2000 3:34 PM
Subject: RE: [gbadev] image file format


> Dennis Ranke wrote:
>
> > Hm, since this is a gba mailing list, i assume you are talking about
> > the gameboy advance which shouldn't have much of a problem decoding
> > jpegs. I have just written a decoder in arm asm which should decode a
> > 240x160 jpeg to 15bit color in about 0.5-1 seconds on an 16mhz arm.
> > This should already be good enough for some uses but i'm aware that
> > it is possible to get the decoder to always take less than half a
> > second. (the dct code uses currently the simplest implementation which
> > takes up to 64 muls per pixel...)
>
> Go for the AAN DCT.. Using that I'm currently at 0.31 MegaPixels per
second
> (about 8fps) using 8:1 compressed images. That's still in a complete C++
> implementation with no assembler yet. I see maybe a marginal increase in
the
> DCT core, though the compiler has done a pretty cool job.
> I expect with some hand tweaking to push this to maybe 10fps, and maybe
then
> eek some more speed through other optimisations.
> AndyM
>
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>

Dennis Ranke wrote:

> Hm, since this is a gba mailing list, i assume you are talking about
> the gameboy advance which shouldn't have much of a problem decoding
> jpegs. I have just written a decoder in arm asm which should decode a
> 240x160 jpeg to 15bit color in about 0.5-1 seconds on an 16mhz arm.
> This should already be good enough for some uses but i'm aware that
> it is possible to get the decoder to always take less than half a
> second. (the dct code uses currently the simplest implementation which
> takes up to 64 muls per pixel...)

Go for the AAN DCT.. Using that I'm currently at 0.31 MegaPixels per second
(about 8fps) using 8:1 compressed images. That's still in a complete C++
implementation with no assembler yet. I see maybe a marginal increase in the
DCT core, though the compiler has done a pretty cool job.
I expect with some hand tweaking to push this to maybe 10fps, and maybe then
eek some more speed through other optimisations.
AndyM

On Tue, 3 Oct 2000, Dennis Ranke wrote:

> Hm, since this is a gba mailing list, i assume you are talking about
> the gameboy advance which shouldn't have much of a problem decoding
> jpegs.

Oops. I had a serious eye-brain-disconnection, and thought the mail was
from the gb-dev list. Of course the GBA can use JPEGs! Sorry everyone, my
bad.

-a

Hi,
      That sounds an interesting program. Any chance of letting us look at
it?
I did look at a C implementation of the decode, but that was years ago.

Sean :-)

> Hm, since this is a gba mailing list, i assume you are talking about
> the gameboy advance which shouldn't have much of a problem decoding
> jpegs. I have just written a decoder in arm asm which should decode a
> 240x160 jpeg to 15bit color in about 0.5-1 seconds on an 16mhz arm.
> This should already be good enough for some uses but i'm aware that
> it is possible to get the decoder to always take less than half a
> second. (the dct code uses currently the simplest implementation which
> takes up to 64 muls per pixel...)
>
> --
> exoticorn/icebird
>
> unsubscribe: gbadev-unsubscribe@egroups.com

In message <Pine.OSF.4.20.0010031456570.2147-100000@...>
           Anders M Montonen <ammonton@...> wrote:

> On Mon, 2 Oct 2000, Vince VE wrote:
>
> <snip>
> > Anyways, that's what I had to say about image compression, I hope it
> > gave you ideas or info that helped you or motivated you.
>
> Well, if you're looking for a technical challenge, at
> http://www.ffd2.com/fridge/chacking/c=hacking19.txt you'll find the
> description (and a link to the source) of a JPEG decoder for an unexpanded
> C64. Probably very impractical for "real" use, but for hack value you
> might try implementing JPEGs on the Gameboy.

Hm, since this is a gba mailing list, i assume you are talking about
the gameboy advance which shouldn't have much of a problem decoding
jpegs. I have just written a decoder in arm asm which should decode a
240x160 jpeg to 15bit color in about 0.5-1 seconds on an 16mhz arm.
This should already be good enough for some uses but i'm aware that
it is possible to get the decoder to always take less than half a
second. (the dct code uses currently the simplest implementation which
takes up to 64 muls per pixel...)

--
exoticorn/icebird

Anders M Montonen wrote:

> Well, if you're looking for a technical challenge, at
> http://www.ffd2.com/fridge/chacking/c=hacking19.txt you'll find the
> description (and a link to the source) of a JPEG decoder for an unexpanded
> C64. Probably very impractical for "real" use, but for hack value you
> might try implementing JPEGs on the Gameboy.

why 'impractical for real use' ? more like 'the most decent image compression
out there' ... (yes, it works like a charm on c64 ;=P)

--
----------------------------------------------------------------------
                                  /^\
                                  \ /
           ASCII RIBBON CAMPAIGN   X   AGAINST HTML JUNK MAIL
                                  / \
----------------------------------------------------------------------
           ___ ___ .___________________ .___________ _______.
   c=64   /   |   \|   \__    ___/     \ \_   _____/ \      \ groepaz
    cgb  /    '    \   | |    | /  \ /  \ |    __)_  /   |   \
     psx \    .    /   | |    |/    '    \|        \/    |    \
      dc  \___|_  /|___| |____|\____|__  /_______  /\____|__  /
                \/     '               \/        \/         \/
        http://www.hitmen-console.org    Hitmen WWW Headquarters
        http://fly.to/hitmen-groepaz     my personal playground
----------------------------------------------------------------------

On Mon, 2 Oct 2000, Vince VE wrote:

<snip>
> Anyways, that's what I had to say about image compression, I hope it
> gave you ideas or info that helped you or motivated you.

Well, if you're looking for a technical challenge, at
http://www.ffd2.com/fridge/chacking/c=hacking19.txt you'll find the
description (and a link to the source) of a JPEG decoder for an unexpanded
C64. Probably very impractical for "real" use, but for hack value you
might try implementing JPEGs on the Gameboy.

-a

Hi,

I remember reading an e-mail about image compression
on the gba. I will share the alternatives I found
regarding image compression.

I just discovered the PNG format (no licence needed, no
royalties to give, absolutly free) It's mission is to be
a substitute to the GIF format. it's decompression doesn't
look demanding at all (in time and in size). It is looseless
and it offers compression results comparable to looseless jpeg
(apparently, it sometimes gives a 2:1 ratio)

I even more recently discovered the CBA format (right about now
actually) it looks amazing but I didn't take a look at the specs
in detail yet (check out: www.coreba.com) also absolutely free.

I also thought of the alternative of having paletted images.

By having a global palette (with the indexes expressed on 12-bits)
It would enable me to have 4096 colors out of 32768 with 12-bits
per color. Obviously, such palettes are big and it would be too
expensive to carry one for each picture, that is why all my pictures
must share that same palette.

It would give an almost effortless 4:3 flat ratio. Also paletted
images can pe compressed further and probably with more compressability
since the colors are quantized.

I am still wondering if 4096 colors would be enought. The concession
is hard to make.

Anyways, that's what I had to say about image compression, I hope it
gave you ideas or info that helped you or motivated you.

Vince

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.

> Now, I'm totally in favor of an AGB emulator for debugging purposes --
> no$gmb has been instrumental in my game development.  But one that is
> created honestly (and none of us official developers can create one
honestly
> because we have the documentation), or one that is created in-house, and
> *kept* in-house is the only legitimate way to go.

I'm currently working on BoycottAdvance, an AGB emulator.
I'm not an official developer, I do not have any copyrighted docs nor a
development kit,
I only downloaded demos made by people and my goal is to try to emulate
these.
I started by writing a debugger since for me it is the main goal of my
emulator :
allow people to code easily their homebrewn demos.
But I think I will release it publicly.
I worked quite the same way for NeoPocott, my Neogeo Pocket emulator.
For Boycott, my Gameboy/Gameboy Color, it was a bit different since I
grabbed unofficial
docs maintained by people who tried to understand Nintendo patents and make
also
tests on real hardware to understand how it works.

Since I don't know exactly the innerworkings of the AGB console, I will try
to test and find
stuff on my own.

> Matt.

a+
Gollum

From: "Collin van Ginkel" <collin@...>

> I can understand why some companies would like a GBA emulator (buy one
> devkit and work with several teams on projects) I don't think it's illegal
> to do that (Or am I totally wrong?)

Emulators are completely legal, as long as they are created using black-box
reverse engineering techniques.  For example, most of the accuracy in my NES
emulator has come from me writing test programs and running them on the real
hardware.

The AGB emulator, however, is an illegal piece of software because it was
written based off of official NOA documents.  Whether these documents were
apprehended in an illicit manner (which they were - no licensed developer
would risk their job releasing an AGB emulator) is immaterial -- the fact
that the information is "proprietary and confidential" means that it can't
be released to the public, or even anyone who hasn't signed an NDA.  The
emulator, in a sense, releases that information to the public; just look at
the register and bit names in the debugger.  Sheesh.

Now, I'm totally in favor of an AGB emulator for debugging purposes --
no$gmb has been instrumental in my game development.  But one that is
created honestly (and none of us official developers can create one honestly
because we have the documentation), or one that is created in-house, and
*kept* in-house is the only legitimate way to go.

This AGB emulator has the potential to really fuck things up for the
legitimate emulator scene as well, and for this I don't appreciate the
author's recklessness in releasing the software.  Word on the streets is
that NOA/NCL is going to drop the hammer soon...

Matt.

Hello Dacium,

Monday, October 02, 2000, 11:58:15 AM, you wrote:

D> They'll probably start looking at it differently when people start
D> making emulators months before the system is even released.

mostly because their own programmers couldnt come up with similar
developement tools then, i guess. a emulator is in many cases
a quick and easy method to debug your program. sure the current
release of GbaEmu is quite far from a "reliable" stage, but you
get the idea..

that's just for my toughts about this matter..

--
Best regards,
  anarko                            anarko@...

Emulation is totally legal, its even totally legal to sell emulation
programs or even hardware devices.

-\| www.handhelds.freeservers.com |/-

----- Original Message -----
From: "Collin van Ginkel" <collin@...>
To: <gbadev@egroups.com>
Sent: Monday, October 02, 2000 7:57 PM
Subject: Re: [gbadev] NDA.


> Hi,
>
> > They'll probably start looking at it differently when people start
> > making emulators months before the system is even released.
>
> I can understand why some companies would like a GBA emulator (buy one
> devkit and work with several teams on projects) I don't think it's illegal
> to do that (Or am I totally wrong?)
>
> Greetz,
>
> Collin van Ginkel
> -
> two tribes - digital happiness
> visit http://www.twotribes.com
>
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>

Hi,

> They'll probably start looking at it differently when people start
> making emulators months before the system is even released.

I can understand why some companies would like a GBA emulator (buy one
devkit and work with several teams on projects) I don't think it's illegal
to do that (Or am I totally wrong?)

Greetz,

Collin van Ginkel
-
two tribes - digital happiness
visit http://www.twotribes.com

They'll probably start looking at it differently when people start
making emulators months before the system is even released.

-\| www.handhelds.freeservers.com |/-

----- Original Message -----
From: "Jeff Frohwein" <jeff@...>
To: <gbadev@egroups.com>
Sent: Monday, October 02, 2000 4:34 PM
Subject: Re: [gbadev] NDA.


> Matthew Conte wrote:
> >
> > All of you licensed AGB coders *do* know you are shattering your NDAs
with
> > nintendo by freely revealing AGB specs and such, right?
>
>   Technically, I'd be willing to guess that most licensed sorts realize
> this. It seems that nintendo and it's lawyers, historically, have been
> indifferent about information passing unless it involves what appears
> to be exact copies of NDA matierials that are posted on a public web site.
> Even then, they ask you to remove the information and then they almost
> always leave you alone if you respond to their requests.
>
>  Their enforcement policy could change in the future but I personally
> doubt it. Handhelds & consoles are becoming so complex that a few
> specifications here & there thrown out on a mailing list are a very
> small fraction of the total "knowledge base" and not worth getting
> prosecution-happy over, IMO.
>
>  Just my 2 bits, :)
>
>  Jeff
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>

> Maybe is the choice between ARM or THUMB code is in fact the choice of
which memory system is used.



Basically ROM and EX_WRAM (external work RAM) are connected to the CPU by a
16-bit bus.  This means that you can fetch a Thumb instruction in one
waitstate and an ARM one in two.  And since Thumb instructions cover the
most common instructions, what you get is a large gain in speed.  WRAM
(internal work RAM) , VRAM, palette RAM etc. are connected to the CPU by a
32-bit bus so  you can place ARM instructions without a fetch penalty.
However, ARM instructions are much more powerful than Thumb instructions so
you can get a gain in speed if you use ARM instructions (plus you have
access to more registers).

Theses are the reasons why Nintendo suggest Thumb in external RAM/ROM, ARM
in internal RAM.

Best regards,
Matt D.

Matthew Conte wrote:
>
> All of you licensed AGB coders *do* know you are shattering your NDAs with
> nintendo by freely revealing AGB specs and such, right?

   Technically, I'd be willing to guess that most licensed sorts realize
this. It seems that nintendo and it's lawyers, historically, have been
indifferent about information passing unless it involves what appears
to be exact copies of NDA matierials that are posted on a public web site.
Even then, they ask you to remove the information and then they almost
always leave you alone if you respond to their requests.

  Their enforcement policy could change in the future but I personally
doubt it. Handhelds & consoles are becoming so complex that a few
specifications here & there thrown out on a mailing list are a very
small fraction of the total "knowledge base" and not worth getting
prosecution-happy over, IMO.

  Just my 2 bits, :)

  Jeff