I saw this on another Asian dealer's site.  They call it the
Afterburner 2, but I have not seen this advertised on the net
anywhere else.


http://ps2modchip.com/search.php?page=blacklit

Thoughts, comments?

Has anyone worked with one of these new kits?


--
Rory Savage

Thanks to everyone who posted to help with my interrupt problem. I've
managed to generate some so now just need to get them under control!
It turns out that I hadn't turned on the flags in 0x4000132
(REG_P1CNT) - didn't know about them until I got the Cowbite docs and
read Pat's comment. The other problem was that that particular
register isn't supported in Cowbite, so I ran it under BoycottAdvance
and it worked!

Thanks again guys,
Adam



--- In gbadev@y..., "gb_feedback" <gb_feedback@y...> wrote:
> --- In gbadev@y..., "airadam13" <adam.braimah@t...> wrote:
> > Hi,
> >
> > Sorry to bother you all with what I'm sure is a pretty noddy
query;
> > I'm trying to put together a trivial interrupt example before I
> begin
> > to use them properly, but I simply can't get the system to
actually
> > generate an interrupt.
>
> Couple of ideas for you. It'll sound vague because I don't
> have my bits of paper with me.
>
> First, I take it you are turning on the other enable
> interrupt bit associated with the interrupt source.
> This will be in a register relating to that source.
>
> Second the reason I spent a whole day getting my first
> interrupt routine doing anything was because I'd
> copied the interrupt function vector table from the Pern
> project. I later downloaded a more recent version, and
> found the cryptic comment that this table must be in the
> correct order, which drew attention to the fact that
> the original one wasn't.
>
> (By the way no flame intended here)
>
> Pat

> I'm having problems with '_call_via_r4' from code now in iwram.
> the problem is that I can put _call_via_rX in rom, ewram, or iwram, BUT
> it
> is called from both the ROM  and iwram (I assume calls that are into a
> different section (out of the PC22/PC24 range)).
>
> is this a gcc bug that needs to be reported ? (I'm using gcc 3.2)

Its not an easy to fix problem, I have a solution that I used but its
complicated and involves the compiler spitting out asm and processing it
myself so that the _call_via_rX are rerouted to ones that work depending
on where we currently are. This was in 2.9, there might be a better way of
doing it in 3.2 with your situation but I dont know it

Initially I tried providing local versions of _call_via_rX (as in included
in the C file) for each file that needs them that are located in the
correct bit of memory, but obviously this is bloated and cumbersome if
done by hand. But it could be considered a quick "fix" from your point of
view for calling out of iwram into rom, since your probably only doing it
in a few files.


Kriss

http://XIXs.com
mailto:Kriss@...
ICQ:2082142(work) and 681874(home)
MSN:krisss@...
AIM:Kriss1923 YAHOO:yah_kriss

From: "Mat" <matth@...>
> You forgot to mention that you need one of the following OS's to use it:
>
> Microsoft Windows® 2000 Professional SP2, Microsoft Window 2000 Server SP2,
> or Microsoft Windows XP Professional.

Actually, this is only partially true.

These packages contain a lot more than just the IDE/compiler.  They also contain
just
about everything you need to develop for the Pocket PC.  I know for certain that
the
IDE of eVC v3 will work on Win98 systems because I've done so in the past.  What
will not run on lesser OSes is the Windows CE emulator.

I have not personally tried running eVC4 on anything other than Win2K, so I
don't know
for certain that it runs on Win98, but I suspect it will.

Oh, BTW, it's also a 300MB+ download.  You can also get either version on CD
directly from Microsoft for something like $12.

- John

I dont know if this helps, this simple program:
http://www.dwelch.com/gba/ataxx.htm uses interrupts based on the vblank int
I think.
Look at init.s in the source.  It was not written for gcc nor does it use
Jeff's crtls but
it might help you figure out whats going on with your program..

David



At 12:05 AM 10/31/2002 +0000, you wrote:
>Hi,
>
>Sorry to bother you all with what I'm sure is a pretty noddy query;
>I'm trying to put together a trivial interrupt example before I begin
>to use them properly, but I simply can't get the system to actually
>generate an interrupt. I think the problem could be in my build
>process - I've never been too hot on that stuff :o) I'm using;
>- DevKitAdvance on Windows
>- crt0.S(v1.28) and lnkscript(v1.3) from www.devrs.com/gba
>In crt0.S, interrupt support has been enabled, as have multiple
>interrupts.
>
>The build process is to;
>- Compile the C source file with;
>         gcc -c -gstabs blah.c
>- Assemble crt0.o
>         as -o crt.S crt.o
>- Build an ELF file
>         gcc -nostartfiles -T lnkscript -o crt0.o blah.o blah.elf -
>Lc:\devkitadv\arm-agb-elf\lib\ -lm
>- Produce the final binary
>         objcopy -O binary blah.elf blah.bin
>
>I did get an error complaining of a non-existent reference to the
>symbol __EH_FRAME_BEGIN__, so after much head scratching and a Google
>search I defined it as char __EH_FRAME_BEGIN__[] = { };
>
>The program runs, but I've looked at the registers with CowBite and
>even though the correct bits are set in REG_IE and REG_IME is on, an
>occurrence of any of the cases intended to trigger an interrupt leave
>REG_IF unchanged.
>
>Assuming this _is_ a build problem, do I need to use -mthumb-
>interwork or something "esoteric" like that?
>
>Apologies for the long post! Any help would be very much appreciated.
>
>Ta,
>Adam
>
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

I'm having similar problems, in the past I gave up with
#define CODE_IN_IWRAM __attribute__ ((section (".iwram"), long_call))
void myFunc( void )  CODE_IN_IWRAM;
as it only worked to call asm routines
but did not work with
void myFunc( void )  { ... }
however I've found (by trial and error) that
A the file name MUST be *.text.iwram.* (i.e. myfunc.text.iwram.c)
and the function implementation
void CODE_IN_IWRAM myFunc( void )  { ... }
(I've used void but could be any return/parameters)
at least compiles, BUT
I'm having problems with '_call_via_r4' from code now in iwram.
the problem is that I can put _call_via_rX in rom, ewram, or iwram, BUT it
is called from both the ROM  and iwram (I assume calls that are into a
different section (out of the PC22/PC24 range)).

is this a gcc bug that needs to be reported ? (I'm using gcc 3.2)

Mike.




----- Original Message -----
From: "j_north2002" <johnny_north@...>
To: <gbadev@yahoogroups.com>
Sent: Tuesday, October 29, 2002 6:27 PM
Subject: [gbadev] compiler questions


> It was suggested to me that for calling functions in the codewave's
> library (the code is to be placed in iwram) that the declarations be
> made like this:
>
> __attribute__(( long_call )) void MP_IntHandler(void);
>
> however, when I compile w/ the __attribute__(( long_call )), I get
> the error:
> main.cpp:37: cannot convert `void (*)()' to `void (*)()' in
> initialization
>
> the start.s file that comes with the example code does this for the
> interupts(i'm not using this code though):
>
> IntrTable:
>     .long   0x00000000
>     .long   0x00000000
>     .long   0x00000000
>     .long   0x00000000
>     .long   0x00000000
>     .long   0x00000000
>     .long   0x00000000
>     .long   0x00000000
>     .long   0x00000000
>     .long   MP_IntHandler
>     .long   0x00000000
>     .long   0x00000000
>     .long   0x00000000
>
> Could someone tell me how the __attribute__(( long_call )) works, if
> it's necessary for calling iwram code etc..
>
> I've indicated -mthumb --mthumb-interwork and -long-calls for the
> cflags if it matters.
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

I had this problem, not being able to generate interupts.  I
eventually found that it was a problem with the crt0.s file.  It
wasn't setting some IRQ flag in some register called CPSR_c.




On Thu, 31 Oct 2002 16:48:31 -0000, "gb_feedback"
<gb_feedback@...> wrote:

>--- In gbadev@y..., "airadam13" <adam.braimah@t...> wrote:
>> Hi,
>>
>> Sorry to bother you all with what I'm sure is a pretty noddy query;
>> I'm trying to put together a trivial interrupt example before I
>begin
>> to use them properly, but I simply can't get the system to actually
>> generate an interrupt.
>
>Couple of ideas for you. It'll sound vague because I don't
>have my bits of paper with me.
>
>First, I take it you are turning on the other enable
>interrupt bit associated with the interrupt source.
>This will be in a register relating to that source.
>
>Second the reason I spent a whole day getting my first
>interrupt routine doing anything was because I'd
>copied the interrupt function vector table from the Pern
>project. I later downloaded a more recent version, and
>found the cryptic comment that this table must be in the
>correct order, which drew attention to the fact that
>the original one wasn't.
>
>(By the way no flame intended here)
>
>Pat
>
>
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>

You forgot to mention that you need one of the following OS's to use it:

Microsoft Windows® 2000 Professional SP2, Microsoft Window 2000 Server SP2,
or Microsoft Windows XP Professional.


----- Original Message -----
From: "John Seghers" <johnse@...>
To: <gbadev@yahoogroups.com>
Sent: Thursday, October 31, 2002 11:41 AM
Subject: Re: [gbadev] Thought this might be of interest


> You can get eMbedded Visual C++ v.4 (yes, that's Microsoft being cute with
> the name) free for the download at
>
http://msdn.microsoft.com/downloads/default.asp?URL=/downloads/sample.asp?ur
l=/MSDN-FILES/027/001/945/msdncompositedoc.xml
> (If that wraps, the complete URL ends with .xml)
>
> I've not yet seriously tried to get something compiled from there onto the
GBA.
> It will only produce executables in the PE format and it doesn't have the
linker flexibility that
> GCC does. I'm sure there's a way to get it to work, I've just not put the
time, effort, and
> likely tool-building in to make it work.
>
> However, if you like the VC++ IDE, that download gets it for you for free,
even if you
> don't use the compiler.
>
> Also, if for some reason you want the V3 of the the compiler, it's
available here:
>
http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?ur
l=/msdn-files/027/001/963/msdncompositedoc.xml
>
> - John
>
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

--- In gbadev@y..., "airadam13" <adam.braimah@t...> wrote:
> Hi,
>
> Sorry to bother you all with what I'm sure is a pretty noddy query;
> I'm trying to put together a trivial interrupt example before I
begin
> to use them properly, but I simply can't get the system to actually
> generate an interrupt.

Couple of ideas for you. It'll sound vague because I don't
have my bits of paper with me.

First, I take it you are turning on the other enable
interrupt bit associated with the interrupt source.
This will be in a register relating to that source.

Second the reason I spent a whole day getting my first
interrupt routine doing anything was because I'd
copied the interrupt function vector table from the Pern
project. I later downloaded a more recent version, and
found the cryptic comment that this table must be in the
correct order, which drew attention to the fact that
the original one wasn't.

(By the way no flame intended here)

Pat

----- Original Message -----
From: "Maciej Sinilo" <yrp@...>
To: <gbadev@yahoogroups.com>
Sent: Thursday, October 31, 2002 11:41 AM
Subject: Re: [gbadev] Timers


>
> Now, writing to timer data register does NOT (according to Cowbite Spec)
reset it, "if a value is written to this register, the timer will henceforth
use that as a starting value".
> Just recently I've also found this info in GBA tek (from no$gba author,
available at
> http://www.work.de/nocash/gbatek.htm):
> "Note: When simultaneously changing the start bit from 0 to 1, and setting
the reload value at the same time (by a single 32bit I/O operation), then
the newly written reload
> value is recognized as new counter value", but I've not tested this on HW
yet (I don't think it works as supposed with VBA).

Cheers for that, I missed the subtly of the "will henceforth use that as a
starting value".

changed the code to
  *((vu16*)0x0400010E)= 0x0002; // stop the timer
  *((vu16*)0x400010C) = 0x0000; // set the start value
  *((vu16*)0x0400010E)= 0x0082; // start the timer (enable clk/256)
... time me ...
  i = *((vu16*)0x400010C); // get the current count.

and it works on the hardware now,

Mike.

You can get eMbedded Visual C++ v.4 (yes, that's Microsoft being cute with
the name) free for the download at
http://msdn.microsoft.com/downloads/default.asp?URL=/downloads/sample.asp?url=/M\
SDN-FILES/027/001/945/msdncompositedoc.xml
(If that wraps, the complete URL ends with .xml)

I've not yet seriously tried to get something compiled from there onto the GBA.
It will only produce executables in the PE format and it doesn't have the linker
flexibility that
GCC does. I'm sure there's a way to get it to work, I've just not put the time,
effort, and
likely tool-building in to make it work.

However, if you like the VC++ IDE, that download gets it for you for free, even
if you
don't use the compiler.

Also, if for some reason you want the V3 of the the compiler, it's available
here:
http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/m\
sdn-files/027/001/963/msdncompositedoc.xml

- John

On 31 Oct 2002 at 4:41, Mike Wynn wrote:

> I have been trying to time some code by using
>
>  *((vu16*)0x0400010E)= 0x0082;
>  *((vu16*)0x400010C) = 0x0000;
>
> .... do some stuff I want to time
>
>  i = *((vu16*)0x400010C);
>
> ... to some stuff I don't
>
>     return i; // the time taken to do the "work"
>
> this seems to work on the vba, but when I try to run this on real
> hardware,it seems as if the timer is not getting reset.
Funny you asked this question, I'm just fighting with timer incompatibilites
between emulators and hardware. Do you really remember values of timer
registers? ;-). Let's
translate this to a little more readable form first:
* 0x400010E = timer 3 control
* 0x400010C = timer 3 data
* 0x0082 = frequency ~262187.5KHz, enable

Now, writing to timer data register does NOT (according to Cowbite Spec) reset
it, "if a value is written to this register, the timer will henceforth use that
as a starting value".
Just recently I've also found this info in GBA tek (from no$gba author,
available at
http://www.work.de/nocash/gbatek.htm):
"Note: When simultaneously changing the start bit from 0 to 1, and setting the
reload value at the same time (by a single 32bit I/O operation), then the newly
written reload
value is recognized as new counter value", but I've not tested this on HW yet (I
don't think it works as supposed with VBA).
HTH,

--
- Maciej Sinilo

I have been trying to time some code by using

  *((vu16*)0x0400010E)= 0x0082;
  *((vu16*)0x400010C) = 0x0000;

.... do some stuff I want to time

  i = *((vu16*)0x400010C);

... to some stuff I don't

     return i; // the time taken to do the "work"

this seems to work on the vba, but when I try to run this on real
hardware,it seems as if the timer is not getting reset.

any ideas ?

Hi,

Sorry to bother you all with what I'm sure is a pretty noddy query;
I'm trying to put together a trivial interrupt example before I begin
to use them properly, but I simply can't get the system to actually
generate an interrupt. I think the problem could be in my build
process - I've never been too hot on that stuff :o) I'm using;
- DevKitAdvance on Windows
- crt0.S(v1.28) and lnkscript(v1.3) from www.devrs.com/gba
In crt0.S, interrupt support has been enabled, as have multiple
interrupts.

The build process is to;
- Compile the C source file with;
	 gcc -c -gstabs blah.c
- Assemble crt0.o
	 as -o crt.S crt.o
- Build an ELF file
	 gcc -nostartfiles -T lnkscript -o crt0.o blah.o blah.elf -
Lc:\devkitadv\arm-agb-elf\lib\ -lm
- Produce the final binary
	 objcopy -O binary blah.elf blah.bin

I did get an error complaining of a non-existent reference to the
symbol __EH_FRAME_BEGIN__, so after much head scratching and a Google
search I defined it as char __EH_FRAME_BEGIN__[] = { };

The program runs, but I've looked at the registers with CowBite and
even though the correct bits are set in REG_IE and REG_IME is on, an
occurrence of any of the cases intended to trigger an interrupt leave
REG_IF unchanged.

Assuming this _is_ a build problem, do I need to use -mthumb-
interwork or something "esoteric" like that?

Apologies for the long post! Any help would be very much appreciated.

Ta,
Adam

Yes ARM does a good job in getting those CDs out, another CD you should get
from them is the
Technical Publications cd, among other things you get an electronic copy of
the ARM ARM (the arm bible)
granted you get a version of it with the ADS eval too, but I think its an
older rev (I think the current rev is rev E).
(I think rev B is the best, blue cover, I dont think there are electronic
versions)...

The 7A88 is a typo it should be 7B88, just trying to understand which
numbers you picked up from where.
(those hex numbers were all computer generated and cut and pasted, the
timer counts and some of the totals
were done by hand and subject to error)...

I think on the green hills you do need to add the extra non-zero bytes from
the 0x3000000 section, when linked properly
everything sits in ROM and the initialized ram is copied during
setup.  (something Jeffs linker scripts
and crt0.s do for gcc).  I cant decide if zero-init memory counts or not,
it does in the sense that the program is going
to use that space, it doesnt in the sense that you dont need to store it in
the rom.

I work with both of these companies so I have to be kind to both:  What
conclusions I draw is that GHS is producing
smaller binaries and ARM is producing faster binaries.  Each company has
their own definition of "better".  When
you switch from speed to size though you only gain a small size gain at the
cost of a big performance gain, more so
with GHS than ARM (granted the shrinkage is more with GHS than with
ARM).  The dhrystone program is a small program
to start with, so, perhaps a size optimization on a much larger program
would have a much larger size change.  If its
still only within one percent or so as these runs showed I wouldnt take the
huge performance hit I would compile for
speed all the time and get speed and a good enough size (esp on the
crippled GBA that needs all the speed help it can get)...

Good luck with the ADS eval, if you need any help getting your first
binaries compiled let me know.  You need to
follow the example where they build for rom using retarget.c, otherwise you
get Angel SWI calls embedded into
your code and its not going to run at all on the GBA...I can post or send
some working examples...

I wish I still had an eval of Metaware, as far as performance goes
Metaware's compiler blows everyone away, I have no idea
how it measures up on size though...If you have not already you can (or
used to) simply download an eval from Metaware
and get an eval license automagically through email or a web page.  Since
we have a relationship with GHS I simply ask
for evals whenever a new release comes out, and they fedex one over, I know
that you can pick up eval cds anytime you find
them at a trade show, Hmmm, looks like you can order the CD from their
website.  ARM never, ever, bugged me about
buying when I order an eval cd, Metaware and GHS will definitely...I can
speak good and bad about all of the compilers
I have used, ARM and gcc are the hardest to get your first working binary
out of (all that Angel debugger stuff).  Getting
malloc to work is hard and easy depending on the platform (and how many
examples you can find), linking it just the
right way is again painful for some and not so for others, etc.

Hey, has anyone tried Microsofts compiler?  I read recently that ARM is the
preferred platform for Windows CE powered
PDAs.  So that means to me they should have an ARM compiler of some
sort.  I dont expect it to be all that competitive
with any of the ones I have mentioned so far, and it may be too heavily
Windows CE embedded,  but I would like to try it if
it works (esp if it is a free download).

Lastly, ARMs website claims the RVCT (RealView Compiler Tools) contains the
ADS v1.2 compiler, which means to me
you can get the ADS compiler for $4000 instead of what? $6500 for the full
version.  I have an email out to ARM waiting
for an answer to what the difference is between the products and if one is
going to replace the other in the long run (like
ADS did to SDT).  Note the RealView debugger is the result of ARM
purchasing Allant early this year or last year, so now
there are four ARM debuggers, I wonder if RVCT is ADS with RealView and
without the other three debuggers...

David
gba at dwelch
dot
com


At 05:12 PM 10/30/2002 +0000, you wrote:
>um, I did a little rearrangement of David's tests & got this
>
>I wanted to compare the absolute basic options of the 3 compilers
>
>                                         Speed                   Space
>                                 size    pre     no
> pre  size    pre     no pre
>Green Hills 3.6         $5D58   4102    5117            $5B44   8635    10295
>ADS 1.2 (842)           $7A88   2715    3292            $7BF0   3254    3985
>gcc 3.2                 $6DC4   3500    4240            $6DF4   3619    4393
>
>All Thumb mode - code in ROM, variables in IWRAM
>Green Hills 3.6 -Ospeed -Ospace
>ADS 1.2 (842)   -Otime  -Ospace
>gcc 3.2         -O3             -Os
>
>did I make a typo or did you David?
>
>leads me to some interesting conclusions ;)
>
>just got ADS 1.2 eval CD this morning, haven't got around to installing yet.
>
>btw I ordered it about 4 days ago, well done ARM :)
>
>
>Dave
>
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

--- In gbadev@y..., "Daniel" <webmaster@i...> wrote:
> I know that many people have asked about how to make a cart.  My
> site has most of what you need inorder to make a working flash cart;
> as far as what I consider to be the most practable approach.  However,
> there are some skills you would need like soldering practice, and
> photo etching of coper clad boards perhaps even electro-plating for
> the via's.  This extra info will be added some time in the near
> future.  http://www.interspecialty.com/game
>
> At the least it gives you some idea of what it would take.  If you
> are a person able to help with this project please contact me.

Very nice, i just want to add that people who are not able to etch can
contact companies like http://www.pcb-pool.com/

PCB Pool also accept Eagle files.

um, I did a little rearrangement of David's tests & got this

I wanted to compare the absolute basic options of the 3 compilers

					 Speed 	 Space
				 size pre no pre size pre no pre
Green Hills 3.6  $5D58 4102 5117  $5B44 8635 10295
ADS 1.2 (842)  $7A88 2715 3292  $7BF0 3254 3985
gcc 3.2 	 $6DC4 3500 4240  $6DF4 3619 4393

All Thumb mode - code in ROM, variables in IWRAM
Green Hills 3.6 -Ospeed -Ospace
ADS 1.2 (842) -Otime -Ospace
gcc 3.2  -O3  -Os

did I make a typo or did you David?

leads me to some interesting conclusions ;)

just got ADS 1.2 eval CD this morning, haven't got around to installing yet.

btw I ordered it about 4 days ago, well done ARM :)


Dave

Hi David,

Here's how you can get ADS to copy the code into Internal Ram. Create a text
with the following content:

------------------------------------------ Scatterfile.txt

RomImage 0x08000000 0x2000000
{
  RomImage 0x08000000
  {
   Boot.o (Init, +First)
   * (+RO)
  }

  FastRam 0x03000000 0x7f00
  {
   your_dhrystone_object.o
   * (+RW,+ZI)
  }
}


------------------------------------------ endof Scatterfile.txt

Then in Codewarrior, go to your project settings, section ARM Linker, change
your Linktype to Scattered, and fill in the "scatter description file" field.
You should also change Boot.o to the entry object, as well as the name for the
dhrystone routine.

Cheers,
Alex.

   ----- Original Message -----
   From: David Welch
   To: gbadev@yahoogroups.com
   Sent: Wednesday, October 30, 2002 3:04 AM
   Subject: RE: [gbadev] Thought this might be of interest


   ....

   Now here is something fun!  Seeing the numbers above I used gcc to compile
   the _program_ to be in IWRAM, I knew what the results would be (arm beats
   thumb)
   but others may not know that.  I have been working on this all day and its
   bed time
   so I think I will put off doing this IWRAM thing with ADS and GHS for some
   other day...

   THUMB
   -O3 2471
   -O2 2537
   -Os 2551

   ARM
   -O3 2224
   -O2 2305
   -Os 2301

   This is a lot of data, I hope I didnt make a typo...

   David

Anyone got any fast whizz bang Triangle/Sphere intersection techniques that are
not heavily reliant on FPU , I've written one that works fine on systems with an
FPU and within a limited range of fixed point but now require slightly more
precision..

Marcus

For those that might care I have done yet another compiler test:

I found this on the ARM website:

"The ARM and Thumb C and Embedded C++ (EC++) compilers are recognized by
the industry as providing the best performance of all available ARM
targeted compilers. Developed and tuned to deliver the tightest code
density, the compilers produce images up to 25% smaller than other leading
tool suites."

And this on the GreenHills website:

"Green Hills Software today announced the industry's most efficient
optimizing C/C++ compiler and assembler for the ARM® family of
microprocessor cores."
...
"Green Hills Software's new compiler outperformed ARM's ADS 1.2 compiler on
a battery of programs collected by Green Hills Software over its 20 years
in the compiler business. These programs include synthetic benchmarks like
SPEC, Stanford, Linpack and Dhrystone, but also customer code spanning a
variety of real-world embedded applications. On the full set of tests,
Green Hills Software's ARM 3.6 compiler generated code that was 17% smaller
than that generated by the ADS 1.2 compiler in ARM Mode and 10% smaller in
Thumb Mode. Both compilers were set to use optimizations that produce
minimum code size."

So I decided to do a little head to head experiment on the GBA. (yes I
threw in gcc)

---- Green Hills v3.6 ----
For starters, when I was checking out v3.5, GHS gave me some pointers on how to
get max (Dhrystone?) speed out of their compiler, they came up with these
options:

-cpu=arm7tm -Ospeed --no_commons -OI -OB

The pre is prefetch enabled no is prefetch disabled, 3/1 is 3/1 timing in
WAITCNT
4/1 is 4/1 timing in WAITCNT, the hex numbers are dumps of the address,
filesz and
memsz from the elf file (both companies claim to be smaller and
faster).  The number
next to pre or no is the timer tick count for the run, the smaller the
number the faster.

THUMB MODE
-cpu=arm7tm -Ospeed --no_commons -OI -OB
08000000 00005D30 00005D30 23856
03000000 0000008A 0000008A 138
0300008C 00000000 00002CC4 11460
total 35454 bytes
3/1 pre-fetch enabled 3517
3/1 no prefetch 4450
4/1 pre 5019
4/1 no  5974

THUMB
-Ospeed
08000000 00005D58 00005D58 23896
03000000 0000008A 0000008A 138
0300008C 00000000 00002CC0 11456
total 35490
3/1 pre 4102
3/1 no  5117
4/1 pre 5792
4/1 no  6844

THUMB
-Ospace
08000000 00005B44 00005B44 23364
03000000 0000008A 0000008A 138
0300008C 00000000 00002CBE 11454
total 34956 bytes
3/1 pre 8635
3/1 no  10295
4/1 pre 12297
4/1 no  13981

ARM MODE
-cpu=arm7tm -Ospeed (it would not run without adding the -cpu option)
08000000 00006118 00006118 24856
03000000 0000008A 0000008A 138
0300008C 00000000 00002CC0 11456
total 36450 bytes
3/1 pre 4716
3/1 no  5636

ARM
-cpu=arm7tm -Ospace
08000000 00005E60 00005E60 24160
03000000 0000008A 0000008A 138
0300008C 00000000 00002CBE 11454
total 35752 bytes
3/1 pre 9516
3/1 no 11178

---- ADS v1.2 build 842 ---

THUMB MODE
-Otime
08000000 00007B88 0000A84C 43084
3/1 pre 2715
3/1 no  3292

-Ospace
08000000 00007AF0 0000A7B4 42932
3/1 pre 3254
3/1 no  3985

-Otime -apcs /interwork
08000000 00007B94 0000A858 43096
3/1 pre 2723
3/1 no 3327

-Ospace -apcs /interwork
08000000 00007B04 0000A7C8 42952
3/1 pre 3296
3/1 no 4094

ARM MODE
-Otime
08000000 00008648 0000B30C 45836
3/1 pre 3258
3/1 no 3840

-Ospace
08000000 00008574 0000B238 45624
3/1 pre 4299
3/1 no 5034

---- gcc 3.2 ----

ARM MODE
-O3
03000000 0000073C 00003244 12868
08000000 00009760 00009760 38752
51620 bytes total
3/1 pre 4967
3/1 no  5719

-O2
03000000 0000073C 00003244 12868
08000000 000097C0 000097C0 38848
51716 bytes total
3/1 pre 5184
3/1 no  5963

-Os
03000000 0000073C 00003244 12868
08000000 000097B8 000097B8 38840
51708 bytes total
3/1 pre 5285
3/1 no  6078

THUMB MODE (dhry_1.c is only -O1 due to compiler bug)
-O3
03000000 0000073C 00003244 12868
08000000 00006DC4 00006DC4 28100
40968 bytes total
3/1 pre 3500
3/1 no  4240

-O2
03000000 0000073C 00003244 12868
08000000 00006DE8 00006DE8 28136
41004 bytes total
3/1 pre 3595
3/1 no  4363

-Os
03000000 0000073C 00003244 12868
08000000 00006DF4 00006DF4 28148
41016 bytes total
3/1 pre 3619
3/1 no  4393


I leave it to the reader to draw your own conclusions...


Now here is something fun!  Seeing the numbers above I used gcc to compile
the _program_ to be in IWRAM, I knew what the results would be (arm beats
thumb)
but others may not know that.  I have been working on this all day and its
bed time
so I think I will put off doing this IWRAM thing with ADS and GHS for some
other day...

THUMB
-O3 2471
-O2 2537
-Os 2551

ARM
-O3 2224
-O2 2305
-Os 2301

This is a lot of data, I hope I didnt make a typo...

David

It was suggested to me that for calling functions in the codewave's
library (the code is to be placed in iwram) that the declarations be
made like this:

__attribute__(( long_call )) void MP_IntHandler(void);

however, when I compile w/ the __attribute__(( long_call )), I get
the error:
main.cpp:37: cannot convert `void (*)()' to `void (*)()' in
initialization

the start.s file that comes with the example code does this for the
interupts(i'm not using this code though):

IntrTable:
     .long   0x00000000
     .long   0x00000000
     .long   0x00000000
     .long   0x00000000
     .long   0x00000000
     .long   0x00000000
     .long   0x00000000
     .long   0x00000000
     .long   0x00000000
     .long   MP_IntHandler
     .long   0x00000000
     .long   0x00000000
     .long   0x00000000

Could someone tell me how the __attribute__(( long_call )) works, if
it's necessary for calling iwram code etc..

I've indicated -mthumb --mthumb-interwork and -long-calls for the
cflags if it matters.

Has anyone used, and documented Hblank synced DMA ?

I have some code that works (on hardware only) but I'm conserned about side
effects.

extern void user_dma_request( const void * src, void * dst, u32 count );
#define user_dma_mem_request( dst, src, ctrl ) user_dma_request( src, dst,
ctrl )

  .global user_dma_request
  .type user_dma_request,function
user_dma_request:
  mov r3, #0x04000000
  add r3, r3, #0xD4
  stmia r3, {r0-r2}
  bx lr

having put my image into ewram, I wait for a vblank then call
  user_dma_mem_request( (u32*)0x06000000, (u32*)0x02000000, 0xB4004B00 );

I assume that a 60 word (u32) tranfer happens each hblank starting at hblank
0
or is it simpler, and just does a 60 word transfer each hsync until finished
so the dma will be ahead of the screen update (due to it running in the
vblank)

also, does anyone know if there is an emulator that supports this mode ?
or am I going to have to attempt a hack on one of the open source emulators
to test my code

Mike.

http://www.dwelch.com/gba/dhry.htm

The ARM tools are pretty damn good once you learn to control them.
When you pay for a copy and support, for a certain period of time
you get free upgrades. I guess that continues of you maintain your support
contract (which is not free certainly), without the support contract
upgrades to a previously purchased version are much less than
a full license (which is what started this thread I think).  The
prices change with time apparently, when 1.2 came out an upgrade from
1.1 was $250 if I remember correctly.

$500 for an academic version is still steep, they should be giving this
stuff away IMO, with their goal of everyone touching an ARM every hour
minute or second...Next time I get to whisper in the ear of someone
high up at ARM (it happens), I will put a few words in for the cause.

Hey, when did the RealView tools come out?  I have been waiting for this
release for a while now (I thought it would be bundled with say an ADS 1.3
though I dont understand whats going on with these separate packages)
I dont know if I agree with this statement (from ARM):

"The ARM and Thumb C and Embedded C++ (EC++) compilers are recognized by
the industry as providing the best performance of all available ARM
targeted compilers. Developed and tuned to deliver the tightest code
density, the compilers produce images up to 25% smaller than other leading
tool suites."

Okay, someone is doing some false advertising here:

"Green Hills Software today announced the industry's most efficient
optimizing C/C++ compiler and assembler for the ARM® family of
microprocessor cores."
...
"Green Hills Software's new compiler outperformed ARM's ADS 1.2 compiler on
a battery of programs collected by Green Hills Software over its 20 years
in the compiler business. These programs include synthetic benchmarks like
SPEC, Stanford, Linpack and Dhrystone, but also customer code spanning a
variety of real-world embedded applications. On the full set of tests,
Green Hills Software's ARM 3.6 compiler generated code that was 17% smaller
than that generated by the ADS 1.2 compiler in ARM Mode and 10% smaller in
Thumb Mode. Both compilers were set to use optimizations that produce
minimum code size."

David

At 12:59 AM 10/28/2002 +0000, you wrote:


> >-----Original Message-----
> >From: Mike Wynn [mailto:mike.wynn@...]
> >Sent: Monday, October 28, 2002 12:03 AM
> >To: gbadev@yahoogroups.com
> >Subject: Re: [gbadev] Thought this might be of interest
>
> >as I read it this mean ...
>
>
> >If you have a valid support licence then this product is free for you
> >(you've already paid) your support licence is not extended by
> >this, so if it
> >runs out in a week, you'll have to pay $'s in a weeks time to
> >renew your
> >support licence.
>
>that's kind of what I figured. It does look as if you only have to pay once
>for a license to use the product though. This is why I was looking at the
>academic license.
>
>I have evaluation CDs on the way so I'll let you know if I find a legit way
>to use this stuff for free :o)
>
>I still prefer gcc though.
>
>
>Dave
>
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

>-----Original Message-----
>From: Mike Wynn [mailto:mike.wynn@...]
>Sent: Monday, October 28, 2002 12:03 AM
>To: gbadev@yahoogroups.com
>Subject: Re: [gbadev] Thought this might be of interest

>as I read it this mean ...


>If you have a valid support licence then this product is free for you
>(you've already paid) your support licence is not extended by
>this, so if it
>runs out in a week, you'll have to pay $'s in a weeks time to
>renew your
>support licence.

that's kind of what I figured. It does look as if you only have to pay once
for a license to use the product though. This is why I was looking at the
academic license.

I have evaluation CDs on the way so I'll let you know if I find a legit way
to use this stuff for free :o)

I still prefer gcc though.


Dave

as I read it this mean ...

> ADS Windows v1.x PC Node Locked
> Valid
> CD only, documents on request.* Support and maintenance contract is not
> extended
> Free
> DS120-UD-30000
If you have a valid support licence then this product is free for you
(you've already paid) your support licence is not extended by this, so if it
runs out in a week, you'll have to pay $'s in a weeks time to renew your
support licence.

> ADS Windows v1.x PC Node Locked
> Expired
> CD only, documents on request.* Includes one years support and maintenance
> Contract
> $1650
> DS120-UG-30000
if you support contract has expired (or you've never had one) then it will
cost you $1650 to get the ADS for ONE pc and it will be supported for one
year.

--- In gbadev@y..., "i7hermes" <i7hermes@y...> wrote:

> So, how do i wait the DMA transfer to finish?

Putting DMA in a non-inline function has always worked for me, as
it takes a couple cycles for the CPU to change the program counter.

--
Damian

http://cmp.imag.fr/ARMProducts.html


$500 for an academic license for ADS - might be useful to those at uni or
something.

not sure what's going on here though - a number of free options I'm about to
investigate

http://www.arm.com/devtools/ads?OpenDocument&View=defaultBody4


ADS Windows v1.x PC Node Locked
Valid
CD only, documents on request.* Support and maintenance contract is not
extended
Free
DS120-UD-30000

ADS Windows v1.x PC Node Locked
Expired
CD only, documents on request.* Includes one years support and maintenance
Contract
$1650
DS120-UG-30000

ADS Windows v1.x PC Floating License
Valid
CD only, documents on request.* Support and maintenance contract is not
extended
Free
DS120-UD-40000

ADS Windows v1.x PC Floating License
Expired
CD only, documents on request.* Includes one years support and maintenance
Contract
$1950
DS120-UG-40000

ADS v1.x Unix Floating License
Valid
CD only, documents on request.* Support and maintenance contract is not
extended
Free
DS120-UD-20000

ADS v1.x Unix Floating License
Expired
CD only, documents on request.*
Includes one years support and maintenance Contract
$1950
DS120-UG-20000

--- In gbadev@y..., "i7hermes" <i7hermes@y...> wrote:
> --- In gbadev@y..., "Dave Murphy" <wintermute2002@n...> wrote:
> >
> > interesting, do you have prefetch enabled and is this on hardware
or
> > emulator?
> >
> > If emulator it may be a bug.
> >
> > It's possible that it is a hw bug - the while(1); will enter a
loop
> > contained entirely within the pipeline which may prevent the DMA
> from
> > locking the bus. If you wait for the DMA to finish, not sure what
> the
> > registers are offhand, then enter an infinite loop you will
> probably find
> > that it works equally well.
> >
> > Dave
>
Ok it seems that you were right about the while loop preventing the
DMA transfer to finish.
As a matter of fact, i tried to use that code:

void AgbMain(void)
{
  DMA_Copy(3,(void*)data,(void*)0x06010000,512,DMA_16NOW);
  while (KEY_UP(K_A)) {}
}

If i look at 0x06010000 before having pressed key A, there is no
data, but after having pressed the key, data is there!!
So, how do i wait the DMA transfer to finish?

--- In gbadev@y..., "Dave Murphy" <wintermute2002@n...> wrote:
>
> interesting, do you have prefetch enabled and is this on hardware or
> emulator?
>
> If emulator it may be a bug.
>
> It's possible that it is a hw bug - the while(1); will enter a loop
> contained entirely within the pipeline which may prevent the DMA
from
> locking the bus. If you wait for the DMA to finish, not sure what
the
> registers are offhand, then enter an infinite loop you will
probably find
> that it works equally well.
>
> Dave

I tried this on visualboyadvance, but i get the same results on other
emulators. I don't know what's the result on hardware.
About prefetch, i don't know what it is, can you tell me more?
I thought, as DMA halts CPU, that whatever i did, waiting for DMA to
finish was automatic.

it may be caused by bad order of writing registers.

   try this macro:

#define DmaCopy(s,d,c)\
{\
          REG_DMA3SAD=(u32)s;\
          REG_DMA3DAD=(u32)d;\
          REG_DMA3CNT_L=c;\
          REG_DMA3CNT_H=DMA_ENABLE;\
}





   bye, porneL


--

1200 603/200 040/25 64M 8.6G 4X 3.1 AGA, GG 989217
[pegazos soon!]