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

Hi

I've recently found the need to compile some C++ code for AGB,
Has anyone got any ideas on how to modify the makefile and maybe
source to make this work?

Regards

Mat

Well, its not quite free, but its defidently ARM friendly.  This
nifty
new product from ARM.  The ARM7TDMI Evaluation Kit.  For the low low
price of $199us, you can get your hands on this nifty board with a
whole bunch of cool ports and stuff on it.  You can clock this baby
at
freq's up to 50mhz, and it has 512k of 32bit wide SRAM and another
512k EEPROM on board.  Its by no means a replacement or even a
suppliment for a real kit, but it is cheap and as a developer you've
sworn the oath to purchase every cool piece of hardware that comes
out.  Check it out here:

http://www.arm.com/sitearchitek/devtools.ns4/iwpList113/D3E8AAAB23AA46
5B8025693600655F87?OpenDocument

But on the topic of free compiler, there's of course GCC.  You can
pick up a pre-build version of GCC with an ARM target for the
DOS/Win9x platform here:

http://celab21.pc.elec.uq.edu.au/~tina/arm-gcc.html

This has no docs with it, you'll have to check out the gcc page for
real info about how to use the ARM compiler, but the general syntax
should be the same as the GNUPro us devrs are used.

-MK

----- Original Message -----

From: bobbyd

To: gbadev@egroups.com

Sent: Thursday, September 28, 2000 11:13 PM

Subject: RE: [gbadev] "An alternative to Gcc or How to avoid the malloc/new nightmare, and other similar stuff" =)

hmm i think your missing the point here Alex, we want to develop a suite of programs that will allow people to develop AGB software at home for free, any commercial software is therefore ruled out.

 

on another point, writing your own malloc and new functions is hardly a nightmare, in fact, i wouldnt be happy using someone elses routines when memory is at such a premium on the AGB, you may want the nice cosy safe surroundings of Visual Studio, but i would go for Visual Slickedit over Visual Studio any day. I have just finished a win32 project using visual studio, and yes, it was nice, but you start to rely on all the bells an whistles of a package like that, and when it's taken away you feel a bit lost!

 

 -----Original Message-----
From: Alex GANEA [mailto:ganea@...]
Sent: 28 September 2000 20:49
To: gbadev@egroups.com
Subject: [gbadev] "An alternative to Gcc or How to avoid the malloc/new nightmare, and other similar stuff" =)

 

Hi guys & gals !

 

 

It seems nobody here heard about the ARM Developer Suite?

Basically its an integratted solution more like the old ARM Software Developement Toolkit 2.5, except (between other things) that it uses Codewarrior as IDE. This tool can output any valid executable format for the gameboy advance (elf/axf/bin), it has a very good ARM 7 TMDI emulator/debugger, and most of the tools you can find in the GCC suite.

Ok now, you might say, Why im gonna change my good ol' GCC for this crap ? ;) I'll tell you why:

 

- first, because its not crap :)

- second, it's a complete gui-driven developement suite more like Visual Studio, with project management, with no DOS-Unix-Batches shit, no makefiles, no linkscripts, etc.

- it has fully working asm/c/c++ & stdlib/memory/stdio support with the ability to retarget all this stuff (useful for embedded systems ;)

- it has a good debugger, with realtime processor emulation

 

All this sounds quite good, so where's the catch?

The problem is that this tool _was not_ specifically written for the gba, so you cant trace your programs with the devkit =( This means that you have to use your old (beta:) debugger!

Anyway, it seems that the AXD debugger has some kind of dll support, so maybe one may write an interface between the devkit and the debugger? (hint,hint) =) I was also told that the guys from ARM are possibly working on this.

 

I just wanted share this with you, as i think this may a better (modern) solution than gcc, so lemme know your impressions!

 

You can order a free evaluation CD on this page: http://www.arm.com/sitearchitek/devtools.ns4/html/dev_tools?OpenDocument&style=Dev_Tools

 

(/Msg me if you need any tips on compiling, it needs some small tweaking)

 

 

PS: You should also take a look at the Applications Library CD, it has a lot of good (optimized) stuff in it like jpeg/mp3/dct... routines (it may be useful, who knows? ;)

 

NOTE: Im not connected to ARM Limited in any way, everything in this mail are my own opinions. =D

 

----------------------------------------------------------

Alexandre GANEA - R & D Departement

Planet Interactive Developement

mailto:aganea@...

----------------------------------------------------------

 

unsubscribe: gbadev-unsubscribe@egroups.com

unsubscribe: gbadev-unsubscribe@egroups.com

Hi Anarko

I meant a point and click game creation system, without any coding involved.

Regards

Mat

----- Original Message -----
From: "anarko" <anarko@...>
To: "Mat" <gbadev@egroups.com>
Sent: Friday, September 29, 2000 12:33 PM
Subject: Re[2]: [gbadev] "An alternative to Gcc or How to avoid the
malloc/new nightmare, and other similar stuff" =)


> Hello Mat,
>
> Friday, September 29, 2000, 12:50:11 AM, you wrote:
>
> M> Hi bobbyd
>
> M> Why not create a GUI based game creation system, whereby the PC GUI
editing
> M> software allows users to create a game and save out a GBA image. The
image
> M> would consist of your engine with a data file tagged onto the end of
it.
> M> If you made it open source then you would get a
> M> large amount of support.
>
> i believe GUI's was already invented. many text editors that
> programmers tend to use also have support for building code & running
> just by a button press or similar. for example the RHIDE environment.
> i believe you wouldnt have many problems configuring it to compile
> your AGB code if this is what you want to do.
> sorry if my tone is rude, i just think its such a waste to see
> people come up with ideas and make them real, when someone else
> already did years ago. the code is written and GNU...
>
> --
> Best regards,
>  anarko                            anarko@...
>
>
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>

Steve Wiseman wrote:
>
> On Fri, 29 Sep 2000, Manfred Linzner wrote:
>
> > I can't go conform with b)
> > ARM code can(*) be alot faster when used for the right kind of routines.
>
> But if you're having trouble keeping the pipeline full from, say, a really
> slow 8-bit ROM, it's possible that the gain you get from 2:1 code
> compression more than makes up for the less-wonderful thumb instruction
> set. Depends, as ever, on your code, the cache size (and I/D split), etc
> etc etc.
> Is there any more data leaking out into the public domain about the exact
> implementation of the GBA Arm?

We only use armcode in fast RAM. so no probs with waitstates =)

--

Manfred Linzner
(Project Manager)
Shin'en Multimedia
http://www.shinen.com
Tel.: ++49 (0)89 785 82 565
Fax.: ++49 (0)89 785 82 535

----- Original Message -----

From: Ontwerper

To: gbadev@egroups.com

Sent: Friday, September 29, 2000 4:49 PM

Subject: Re: [gbadev] -mthumb-interwork answer

Hi,

 

I must indeed correct myself: Thumb is not faster then ARM. That is: most of the time..

 

My first thought was that the instruction gets faster through the pipeline and that's (absolute) not true.

Each of the Thumb instructions has an corresponding ARM instruction. And not only corresponding but also has the same effect on the processor. According to the datasheet the instruction cycle times of the Thumb's are identical to that of the equivalent ARM's.

The hidden joke is that the Thumb instructions on runtime are converted to there ARM instructions.

This is done without performance loss but on the other side also with no performance gain. Thus Thumb is not faster then ARM (and not slower).  Also: Thumb instructions are a subset of ARM. The most used ARM's has THUMB 'notations' but not all of them. It is thus possible to use a very powerful ARM instruction that should take a lot of Thumb's to archive the same effect. (I don't have an example of that :))

 

But wait... Now something nice: When the ARM7 processor is connected to 16-bit memory the Thumb code should provide 160% of the ARM code performance. And what memory system has the GBA: a 16-bit or 32-bit? ( I don't know but I expect 16bit Rom/Ram )

 

According the code size: I haven't seen it in practice but in theory the Thumb code should be 65% of the size of the ARM code.

 

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

 

Grtnx,

 

Hans

----- Original Message -----

From: Andy Mucho

To: gbadev@egroups.com

Sent: Friday, September 29, 2000 4:05 PM

Subject: RE: [gbadev] -mthumb-interwork answer

-----Original Message-----
From: bobbyd [mailto:bobbydigital@...]
Sent: 29 September 2000 14:30
To: gbadev@egroups.com
Subject: RE: [gbadev] -mthumb-interwork answer

it's not faster than ARM that's the point  ,  if you want small code, 

 use THUMB if you want fast code use ARM ok? 

The difference in code size is typically not that noticeable from what I've seen when used in *real* code. As a rule of thumb :) 32bit ARM code in WRAM 16bit Thumb code in ROM/EXWRAM..

 

Then again this whole debate is meaningless since the whole argument is down to how efficient you can make the Thumb code instruction for instruction Vs ARM code. If with one ARM instruction you can achieve the same or *more* than with 2 Thumb opcodes then ARM is obviously better.

I'll be saying no more on the matter, since I think the whole ARM Thumb idea is a bit of a marketing ploy/scam anyway :) I would rather have had all those gates wasted on the Thumb decoder put to good use in the form of a small multi-way cache..

 

m00

 

unsubscribe: gbadev-unsubscribe@egroups.com

unsubscribe: gbadev-unsubscribe@egroups.com

----- Original Message -----

From: Andy Mucho

To: gbadev@egroups.com

Sent: Friday, September 29, 2000 4:05 PM

Subject: RE: [gbadev] -mthumb-interwork answer

-----Original Message-----
From: bobbyd [mailto:bobbydigital@...]
Sent: 29 September 2000 14:30
To: gbadev@egroups.com
Subject: RE: [gbadev] -mthumb-interwork answer

it's not faster than ARM that's the point  ,  if you want small code, 

 use THUMB if you want fast code use ARM ok? 

The difference in code size is typically not that noticeable from what I've seen when used in *real* code. As a rule of thumb :) 32bit ARM code in WRAM 16bit Thumb code in ROM/EXWRAM..

 

Then again this whole debate is meaningless since the whole argument is down to how efficient you can make the Thumb code instruction for instruction Vs ARM code. If with one ARM instruction you can achieve the same or *more* than with 2 Thumb opcodes then ARM is obviously better.

I'll be saying no more on the matter, since I think the whole ARM Thumb idea is a bit of a marketing ploy/scam anyway :) I would rather have had all those gates wasted on the Thumb decoder put to good use in the form of a small multi-way cache..

 

m00

 

unsubscribe: gbadev-unsubscribe@egroups.com

-----Original Message-----
From: bobbyd [mailto:bobbydigital@...]
Sent: 29 September 2000 14:30
To: gbadev@egroups.com
Subject: RE: [gbadev] -mthumb-interwork answer

it's not faster than ARM that's the point  ,  if you want small code, 

 use THUMB if you want fast code use ARM ok? 

On Fri, 29 Sep 2000, Manfred Linzner wrote:

> I can't go conform with b)
> ARM code can(*) be alot faster when used for the right kind of routines.

But if you're having trouble keeping the pipeline full from, say, a really
slow 8-bit ROM, it's possible that the gain you get from 2:1 code
compression more than makes up for the less-wonderful thumb instruction
set. Depends, as ever, on your code, the cache size (and I/D split), etc
etc etc.
Is there any more data leaking out into the public domain about the exact
implementation of the GBA Arm?

Steve.

> I think there are 3 reasons to use Thumb code:
> a) It takes less space to store (16bit).
> b) It's faster then ARM code
> c) and last but not least: good big old N suggests to use Thumb for code in
Rom ( because has slower memory access

I can't go conform with b)
ARM code can(*) be alot faster when used for the right kind of routines.

--

Manfred Linzner
(Project Manager)
Shin'en Multimedia
http://www.shinen.com
Tel.: ++49 (0)89 785 82 565
Fax.: ++49 (0)89 785 82 535

anarko, thanks for the help, i wasnt suggesting that i dive right in there
and write a bespoke system, i was just suggesting that people could group
togeather to put together a free dev kit, what it's based on doesnt matter
as long as it works!, so do you have information about the gcc ARM compiler?
:o)

-----Original Message-----
From: anarko [mailto:anarko@...]
Sent: 29 September 2000 12:33
To: Mat
Subject: Re[2]: [gbadev] "An alternative to Gcc or How to avoid the
malloc/new nightmare, and other similar stuff" =)


Hello Mat,

Friday, September 29, 2000, 12:50:11 AM, you wrote:

M> Hi bobbyd

M> Why not create a GUI based game creation system, whereby the PC GUI
editing
M> software allows users to create a game and save out a GBA image. The
image
M> would consist of your engine with a data file tagged onto the end of it.
M> If you made it open source then you would get a
M> large amount of support.

i believe GUI's was already invented. many text editors that
programmers tend to use also have support for building code & running
just by a button press or similar. for example the RHIDE environment.
i believe you wouldnt have many problems configuring it to compile
your AGB code if this is what you want to do.
sorry if my tone is rude, i just think its such a waste to see
people come up with ideas and make them real, when someone else
already did years ago. the code is written and GNU...

--
Best regards,
  anarko                            anarko@...




unsubscribe: gbadev-unsubscribe@egroups.com

-----Original Message-----
From: Ontwerper [mailto:ontwerper@...]
Sent: 29 September 2000 14:21
To: gbadev@egroups.com
Subject: Re: [gbadev] -mthumb-interwork answer

Hi,

 

I think there are 3 reasons to use Thumb code:

a) It takes less space to store (16bit).

b) It's faster then ARM code

c) and last but not least: good big old N suggests to use Thumb for code in Rom ( because has slower memory access time..) and ARM for (ext)Ram

 

grtnx,

Hans

 

----- Original Message -----

From: Giovanni Bajo

To: gbadev@egroups.com

Sent: Thursday, September 28, 2000 6:00 PM

Subject: RE: [gbadev] -mthumb-interwork answer

Ok, so let's go for a more complex question: why one should use THUMB code?
Isn't that the old 16bit compatibility mode available on the processor? Why
not using ARM assembly only?

---
Giovanni Bajo
Lead Programmer

Protonic Interactive
www.protonic.net

a brand of Prograph Research S.r.l.
www.prograph.it


> -----Original Message-----
> From: Lao Tse [mailto:agb_n@...]
> Sent: Thursday, September 28, 2000 5:46 PM
> To: gbadev@egroups.com
> Subject: [gbadev] -mthumb-interwork answer
>
>
> hi, i answer myself
>
> The GNUPro toolkit has two compilers, one of which produces ARM
> assembler,
> and the other produces THUMB assembler. If the
> programmer wants to use just one instruction set to compile their program
> then no special procedures need to be followed, other than
> selecting the correct compiler. If the programmer wants to use both
> instruction sets in their program, then they must separate the ARM
> and THUMB parts of their program into separate files and compile each
> individually, while also specifiying the -mthumb-interwork
> command line flag. When the assembled object files are linked
> together the
> linker will generate special code to switch between the two
> instruction sets whenever a call is made from an ARM function to a THUMB
> function or vice versa.
>
> sorry for asking before reading! :)
>
> LaoTse
>
> _________________________________________________________________________
> 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.
>
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>



unsubscribe: gbadev-unsubscribe@egroups.com

unsubscribe: gbadev-unsubscribe@egroups.com

----- Original Message -----

From: Giovanni Bajo

To: gbadev@egroups.com

Sent: Thursday, September 28, 2000 6:00 PM

Subject: RE: [gbadev] -mthumb-interwork answer

Ok, so let's go for a more complex question: why one should use THUMB code?
Isn't that the old 16bit compatibility mode available on the processor? Why
not using ARM assembly only?

---
Giovanni Bajo
Lead Programmer

Protonic Interactive
www.protonic.net

a brand of Prograph Research S.r.l.
www.prograph.it


> -----Original Message-----
> From: Lao Tse [mailto:agb_n@...]
> Sent: Thursday, September 28, 2000 5:46 PM
> To: gbadev@egroups.com
> Subject: [gbadev] -mthumb-interwork answer
>
>
> hi, i answer myself
>
> The GNUPro toolkit has two compilers, one of which produces ARM
> assembler,
> and the other produces THUMB assembler. If the
> programmer wants to use just one instruction set to compile their program
> then no special procedures need to be followed, other than
> selecting the correct compiler. If the programmer wants to use both
> instruction sets in their program, then they must separate the ARM
> and THUMB parts of their program into separate files and compile each
> individually, while also specifiying the -mthumb-interwork
> command line flag. When the assembled object files are linked
> together the
> linker will generate special code to switch between the two
> instruction sets whenever a call is made from an ARM function to a THUMB
> function or vice versa.
>
> sorry for asking before reading! :)
>
> LaoTse
>
> _________________________________________________________________________
> 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.
>
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>



unsubscribe: gbadev-unsubscribe@egroups.com

GCC...
does someone know where to d/l GCC binaries for ARM ?


D.F.



> -----Oorspronkelijk bericht-----
> Van: anarko [mailto:anarko@...]
> Verzonden: vrijdag 29 september 2000 13:33
> Aan: Mat
> Onderwerp: Re[2]: [gbadev] "An alternative to Gcc or How to avoid the
> malloc/new nightmare, and other similar stuff" =)
>
>
> Hello Mat,
>
> Friday, September 29, 2000, 12:50:11 AM, you wrote:
>
> M> Hi bobbyd
>
> M> Why not create a GUI based game creation system, whereby
> the PC GUI editing
> M> software allows users to create a game and save out a GBA
> image. The image
> M> would consist of your engine with a data file tagged onto
> the end of it.
> M> If you made it open source then you would get a
> M> large amount of support.
>
> i believe GUI's was already invented. many text editors that
> programmers tend to use also have support for building code & running
> just by a button press or similar. for example the RHIDE environment.
> i believe you wouldnt have many problems configuring it to compile
> your AGB code if this is what you want to do.
> sorry if my tone is rude, i just think its such a waste to see
> people come up with ideas and make them real, when someone else
> already did years ago. the code is written and GNU...
>
> --
> Best regards,
>  anarko                            anarko@...
>
>
>
> -------------------------- eGroups Sponsor
> -------------------------~-~>
> Free @Backup service!  Click here for your free trial of @Backup.
> @Backup is the most convenient way to securely protect and access
> your files online.  Try it now and receive 300 MyPoints.
> http://click.egroups.com/1/6348/0/_/_/_/970227110/
> --------------------------------------------------------------
> -------_->
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>

Hello Mat,

Friday, September 29, 2000, 12:50:11 AM, you wrote:

M> Hi bobbyd

M> Why not create a GUI based game creation system, whereby the PC GUI editing
M> software allows users to create a game and save out a GBA image. The image
M> would consist of your engine with a data file tagged onto the end of it.
M> If you made it open source then you would get a
M> large amount of support.

i believe GUI's was already invented. many text editors that
programmers tend to use also have support for building code & running
just by a button press or similar. for example the RHIDE environment.
i believe you wouldnt have many problems configuring it to compile
your AGB code if this is what you want to do.
sorry if my tone is rude, i just think its such a waste to see
people come up with ideas and make them real, when someone else
already did years ago. the code is written and GNU...

--
Best regards,
  anarko                            anarko@...

the movie could be smaller if mpg had overlay support and the background
was....
never mind.

D.F.


> -----Oorspronkelijk bericht-----
> Van: Collin van Ginkel [mailto:collin@...]
> Verzonden: vrijdag 29 september 2000 12:41
> Aan: gbadev@egroups.com
> Onderwerp: Re: [gbadev] Re: *The Incredible* Iridion AGB movie
>
>
> Hi,
>
> I was referring to the tunnel sections in Stardust for Amiga.
>
> Greetings,
>
> Collin van Ginkel
> -
> two tribes - digital happiness
> visit http://www.twotribes.com
>
>
> > From: Ville Helin <tursas@...>
> > Reply-To: gbadev@egroups.com
> > Date: Fri, 29 Sep 2000 13:28:02 +0300
> > To: gbadev@egroups.com
> > Subject: Re: [gbadev] Re: *The Incredible* Iridion AGB movie
> >
> > On Tue, 26 Sep 2000, Collin van Ginkel wrote:
> >
> >>> I remember this group, your game look likes at Stardust
> of Super Stardust
> >>> for 500/1200. (tunnel part, maybe also to Microcosm on CD 32)
> >>
> >> Only ten times better :)
> >
> > I'd say 1:1.0005 identical. ;)
> >
> >
> > --
> > ammw
> > aa_                              ####L
> > ###                             J#####, ____   ___
> > ###            _a_              J###########  J###
>          d##_  am
> > ###L   __     J###K           g#############  d###Q
>  _ww__  _####m###
> > ####wg####    d####w          ##############m######M###m_
> d################
> > ##########L   #######mm_
> J###########################___##M"9############
> > #######@###m_d####@@####m_
> J#####M"""#####"""0########@PM##"   ############
> > ######   ########P  J######__#####K    "#@"    7#####M""
>     J######@PP@##
> > P""#@"    9P"  "@    F   0###@P9M"              ~""""
>      """"""
> > ""
> >
> >
> >
> > unsubscribe: gbadev-unsubscribe@egroups.com
> >
> >
> >
>
>
> -------------------------- eGroups Sponsor
> -------------------------~-~>
> eLerts
> It's Easy. It's Fun. Best of All, it's Free!
> http://click.egroups.com/1/9068/0/_/_/_/970224094/
> --------------------------------------------------------------
> -------_->
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>

Hi,

I was referring to the tunnel sections in Stardust for Amiga.

Greetings,

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


> From: Ville Helin <tursas@...>
> Reply-To: gbadev@egroups.com
> Date: Fri, 29 Sep 2000 13:28:02 +0300
> To: gbadev@egroups.com
> Subject: Re: [gbadev] Re: *The Incredible* Iridion AGB movie
>
> On Tue, 26 Sep 2000, Collin van Ginkel wrote:
>
>>> I remember this group, your game look likes at Stardust of Super Stardust
>>> for 500/1200. (tunnel part, maybe also to Microcosm on CD 32)
>>
>> Only ten times better :)
>
> I'd say 1:1.0005 identical. ;)
>
>
> --
> ammw
> aa_                              ####L
> ###                             J#####, ____   ___
> ###            _a_              J###########  J###                   d##_  am
> ###L   __     J###K           g#############  d###Q          _ww__  _####m###
> ####wg####    d####w          ##############m######M###m_   d################
> ##########L   #######mm_     J###########################___##M"9############
> #######@###m_d####@@####m_   J#####M"""#####"""0########@PM##"   ############
> ######   ########P  J######__#####K    "#@"    7#####M""        J######@PP@##
> P""#@"    9P"  "@    F   0###@P9M"              ~""""            """"""
> ""
>
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>

On Tue, 26 Sep 2000, Collin van Ginkel wrote:

> > I remember this group, your game look likes at Stardust of Super Stardust
> > for 500/1200. (tunnel part, maybe also to Microcosm on CD 32)
>
> Only ten times better :)

I'd say 1:1.0005 identical. ;)


--
                                  ammw
aa_                              ####L
###                             J#####, ____   ___
###            _a_              J###########  J###                   d##_  am
###L   __     J###K           g#############  d###Q          _ww__  _####m###
####wg####    d####w          ##############m######M###m_   d################
##########L   #######mm_     J###########################___##M"9############
#######@###m_d####@@####m_   J#####M"""#####"""0########@PM##"   ############
######   ########P  J######__#####K    "#@"    7#####M""        J######@PP@##
P""#@"    9P"  "@    F   0###@P9M"              ~""""            """"""
                           ""

no the cart size is 32MB which is 256Mbit or
16MB carts have 128Mbits.
-\| www.handhelds.freeservers.com |/-

----- Original Message -----
From: "bobbyd" <bobbydigital@...>
To: <gbadev@egroups.com>
Sent: Friday, September 29, 2000 7:15 AM
Subject: RE: [gbadev] cart sizes


> so in actual fact the cart size is 16Mbits therefore only 2 Mega Bytes ?
>
> -----Original Message-----
> From: Manfred Linzner [mailto:linzner@...]
> Sent: 28 September 2000 22:06
> To: gbadev@egroups.com
> Subject: Re: [gbadev] cart sizes
>
>
> > ok, lets get this straight, you say Mbit suggesting Mega bits, not
bytes,
> > this is often confusing, surely Mb (Mega Bits) would be eight times
> smaller
> > than MB MegaBytes, am i right???
>
> exactly
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>

I added 'pooled' allocations to my memory handler. You can allocate
in the normal way of course; memptr = AllocateMemory(), but you can
also poolptr = AllocatePool() to avoid potential fragmentation issues.

In your example, you could allocate a pool the size of 20 bullets and
alloc/free at will. I tend to do this instead of using static arrays
because the memory system tracks the bejesus out of anything alloc'ed
and will tell me the instant something is clobbered. That's very hard
to do with static arrays.


-- Bob
One Man Band
http://www.onemanband.com

--- In gbadev@egroups.com, Matthew Davies <MDavies@a...> wrote:
> Don't bother about fragmentation (especially on the AGB).  When
writing a
> game for a console, fragmentation can be avoided by proper
algorithms.  For
> example, if you are firing of bullets in a game, you can malloc
when the
> bullet starts and free when they hit something - this will lead to
> fragmentation.  What you should do is at the beginning of a game,
allocate
> memory for an array of, say, 20 bullet structures which you reuse
and
> completely avoid fragmentation.
>
> Matt.
>
>
> > -----Original Message-----
> > From: Manfred Linzner [mailto:linzner@s...]
> > Sent: Thursday, September 28, 2000 11:49
> > To: gbadev@egroups.com
> > Subject: Re: [gbadev] malloc()?
> >
> >
> > > malloc has not been implemented so will always return NULL.
> >  Perhaps in the
> > > final libraries it could be but I wrote my own memory
> > management code to
> > > handle EX_WRAM.  It was quite simple and it was based on
> > the z_alloc() as
> > > found in the DOOM source code.
> >
> > there is some implementation code there.. well, even quite alot..
> > tho not functional, as you said.
> >
> > i already did some allocation code in my shared lib but its very
very
> > plain and simple.. eg takes no look for fragmentation
> >
> >
> > --
> >
> > Manfred Linzner
> > (Project Manager)
> > Shin'en Multimedia
> > http://www.shinen.com
> > Tel.: ++49 (0)89 785 82 565
> > Fax.: ++49 (0)89 785 82 535
> > -------------------------- eGroups Sponsor
> > -------------------------~-~>
> > eGroups eLerts
> > It's Easy. It's Fun. Best of All, it's Free!
> > http://click.egroups.com/1/9067/0/_/_/_/970138051/
> > --------------------------------------------------------------
> > -------_->
> >
> > unsubscribe: gbadev-unsubscribe@egroups.com
> >
> >
> >
> >

--- In gbadev@egroups.com, Manfred Linzner <linzner@s...> wrote:
> > Write your own ALLOC functions is the best bet IMHO...
>
> i'll have to, i guess. I just browsed through the malloc code.
> malloc and calloc should work but they dont. cant find the bug
> without major debugging the libs.
>
> well, so i will do my own stuff now... =)
>
> its only strange that does function do not work.

Maybe the Sony Japan engineers moved on to Nintendo. ;)


-- Bob
One Man Band
http://www.onemanband.com

The GBA can directly address 256mbit memory spaces, which equates to a
maximum cart size (without any bank switching in carts) of 32 megabytes,
plenty of space for even (disgusting) FMV full carts. Though obviuosly since
32 megabyte roms aren't exactly cheap or widely available, they may be in
the future. So I'd be guessing that most carts will be in the range of 4-8
megabytes at first, since those types of roms are relatively cheap. Of
course, as technology drops prices and increases memory densities, 16, 24,
and 32 megabyte carts will become more of a reality. But unless a game has
weeks and weeks of play value, I think 32MB is wasting space.

$0.02,

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

-----Original Message-----
From: Mat [mailto:matth@...]
Sent: 28 September 2000 23:50
To: gbadev@egroups.com
Subject: Re: [gbadev] "An alternative to Gcc or How to avoid the malloc/new nightmare, and other similar stuff" =)

Hi bobbyd

 

Why not create a GUI based game creation system, whereby the PC GUI editing

software allows users to create a game and save out a GBA image. The image would consist of your engine with a data file tagged onto the end of it. If you made it open source then you would get a large amount of support.

 

Regards

 

Mat

 

----- Original Message -----

From: bobbyd

To: gbadev@egroups.com

Sent: Thursday, September 28, 2000 10:13 PM

Subject: RE: [gbadev] "An alternative to Gcc or How to avoid the malloc/new nightmare, and other similar stuff" =)

hmm i think your missing the point here Alex, we want to develop a suite of programs that will allow people to develop AGB software at home for free, any commercial software is therefore ruled out.

 

on another point, writing your own malloc and new functions is hardly a nightmare, in fact, i wouldnt be happy using someone elses routines when memory is at such a premium on the AGB, you may want the nice cosy safe surroundings of Visual Studio, but i would go for Visual Slickedit over Visual Studio any day. I have just finished a win32 project using visual studio, and yes, it was nice, but you start to rely on all the bells an whistles of a package like that, and when it's taken away you feel a bit lost!

 

Visual Slickedit is the best editor i've ever used, you can use it do develop in any language on any system and have auto completion, syntax highlighting and all your nice programming aides, even in ARM / THUM asm!

 

oh well, that's the end of a long and rather pointless mail, thanks for your time ;o)

 

rob

 

 

 -----Original Message-----
From: Alex GANEA [mailto:ganea@...]
Sent: 28 September 2000 20:49
To: gbadev@egroups.com
Subject: [gbadev] "An alternative to Gcc or How to avoid the malloc/new nightmare, and other similar stuff" =)

 

Hi guys & gals !

 

 

It seems nobody here heard about the ARM Developer Suite?

Basically its an integratted solution more like the old ARM Software Developement Toolkit 2.5, except (between other things) that it uses Codewarrior as IDE. This tool can output any valid executable format for the gameboy advance (elf/axf/bin), it has a very good ARM 7 TMDI emulator/debugger, and most of the tools you can find in the GCC suite.

Ok now, you might say, Why im gonna change my good ol' GCC for this crap ? ;) I'll tell you why:

 

- first, because its not crap :)

- second, it's a complete gui-driven developement suite more like Visual Studio, with project management, with no DOS-Unix-Batches shit, no makefiles, no linkscripts, etc.

- it has fully working asm/c/c++ & stdlib/memory/stdio support with the ability to retarget all this stuff (useful for embedded systems ;)

- it has a good debugger, with realtime processor emulation

 

All this sounds quite good, so where's the catch?

The problem is that this tool _was not_ specifically written for the gba, so you cant trace your programs with the devkit =( This means that you have to use your old (beta:) debugger!

Anyway, it seems that the AXD debugger has some kind of dll support, so maybe one may write an interface between the devkit and the debugger? (hint,hint) =) I was also told that the guys from ARM are possibly working on this.

 

I just wanted share this with you, as i think this may a better (modern) solution than gcc, so lemme know your impressions!

 

You can order a free evaluation CD on this page: http://www.arm.com/sitearchitek/devtools.ns4/html/dev_tools?OpenDocument&style=Dev_Tools

 

(/Msg me if you need any tips on compiling, it needs some small tweaking)

 

 

PS: You should also take a look at the Applications Library CD, it has a lot of good (optimized) stuff in it like jpeg/mp3/dct... routines (it may be useful, who knows? ;)

 

NOTE: Im not connected to ARM Limited in any way, everything in this mail are my own opinions. =D

 

----------------------------------------------------------

Alexandre GANEA - R & D Departement

Planet Interactive Developement

mailto:aganea@...

----------------------------------------------------------

 

unsubscribe: gbadev-unsubscribe@egroups.com

unsubscribe: gbadev-unsubscribe@egroups.com

unsubscribe: gbadev-unsubscribe@egroups.com

> Anyway, imho 32Mbit is really alot. When considering using packed grafix
and

Speaking of compression, anyone have recommendations for the most dense
graphic and sound formats/algorithms?

Thanks in advance

Mike

----- Original Message -----

From: bobbyd

To: gbadev@egroups.com

Sent: Thursday, September 28, 2000 10:13 PM

Subject: RE: [gbadev] "An alternative to Gcc or How to avoid the malloc/new nightmare, and other similar stuff" =)

hmm i think your missing the point here Alex, we want to develop a suite of programs that will allow people to develop AGB software at home for free, any commercial software is therefore ruled out.

 

on another point, writing your own malloc and new functions is hardly a nightmare, in fact, i wouldnt be happy using someone elses routines when memory is at such a premium on the AGB, you may want the nice cosy safe surroundings of Visual Studio, but i would go for Visual Slickedit over Visual Studio any day. I have just finished a win32 project using visual studio, and yes, it was nice, but you start to rely on all the bells an whistles of a package like that, and when it's taken away you feel a bit lost!

 

Visual Slickedit is the best editor i've ever used, you can use it do develop in any language on any system and have auto completion, syntax highlighting and all your nice programming aides, even in ARM / THUM asm!

 

oh well, that's the end of a long and rather pointless mail, thanks for your time ;o)

 

rob

 

 

 -----Original Message-----
From: Alex GANEA [mailto:ganea@...]
Sent: 28 September 2000 20:49
To: gbadev@egroups.com
Subject: [gbadev] "An alternative to Gcc or How to avoid the malloc/new nightmare, and other similar stuff" =)

 

Hi guys & gals !

 

 

It seems nobody here heard about the ARM Developer Suite?

Basically its an integratted solution more like the old ARM Software Developement Toolkit 2.5, except (between other things) that it uses Codewarrior as IDE. This tool can output any valid executable format for the gameboy advance (elf/axf/bin), it has a very good ARM 7 TMDI emulator/debugger, and most of the tools you can find in the GCC suite.

Ok now, you might say, Why im gonna change my good ol' GCC for this crap ? ;) I'll tell you why:

 

- first, because its not crap :)

- second, it's a complete gui-driven developement suite more like Visual Studio, with project management, with no DOS-Unix-Batches shit, no makefiles, no linkscripts, etc.

- it has fully working asm/c/c++ & stdlib/memory/stdio support with the ability to retarget all this stuff (useful for embedded systems ;)

- it has a good debugger, with realtime processor emulation

 

All this sounds quite good, so where's the catch?

The problem is that this tool _was not_ specifically written for the gba, so you cant trace your programs with the devkit =( This means that you have to use your old (beta:) debugger!

Anyway, it seems that the AXD debugger has some kind of dll support, so maybe one may write an interface between the devkit and the debugger? (hint,hint) =) I was also told that the guys from ARM are possibly working on this.

 

I just wanted share this with you, as i think this may a better (modern) solution than gcc, so lemme know your impressions!

 

You can order a free evaluation CD on this page: http://www.arm.com/sitearchitek/devtools.ns4/html/dev_tools?OpenDocument&style=Dev_Tools

 

(/Msg me if you need any tips on compiling, it needs some small tweaking)

 

 

PS: You should also take a look at the Applications Library CD, it has a lot of good (optimized) stuff in it like jpeg/mp3/dct... routines (it may be useful, who knows? ;)

 

NOTE: Im not connected to ARM Limited in any way, everything in this mail are my own opinions. =D

 

----------------------------------------------------------

Alexandre GANEA - R & D Departement

Planet Interactive Developement

mailto:aganea@...

----------------------------------------------------------

 

unsubscribe: gbadev-unsubscribe@egroups.com

unsubscribe: gbadev-unsubscribe@egroups.com

> hmm i think your missing the point here Alex, we want to develop a suite of
programs that will allow people to develop AGB software at home for
> free, any commercial software is therefore ruled out.

free or commercial, im thankfull for any tools that make developing easier.
Every good tool can have it's price imho.

so in actual fact the cart size is 16Mbits therefore only 2 Mega Bytes ?

-----Original Message-----
From: Manfred Linzner [mailto:linzner@...]
Sent: 28 September 2000 22:06
To: gbadev@egroups.com
Subject: Re: [gbadev] cart sizes


> ok, lets get this straight, you say Mbit suggesting Mega bits, not bytes,
> this is often confusing, surely Mb (Mega Bits) would be eight times
smaller
> than MB MegaBytes, am i right???

exactly

unsubscribe: gbadev-unsubscribe@egroups.com

 

Hi guys & gals !

 

 

It seems nobody here heard about the ARM Developer Suite?

Basically its an integratted solution more like the old ARM Software Developement Toolkit 2.5, except (between other things) that it uses Codewarrior as IDE. This tool can output any valid executable format for the gameboy advance (elf/axf/bin), it has a very good ARM 7 TMDI emulator/debugger, and most of the tools you can find in the GCC suite.

Ok now, you might say, Why im gonna change my good ol' GCC for this crap ? ;) I'll tell you why:

 

- first, because its not crap :)

- second, it's a complete gui-driven developement suite more like Visual Studio, with project management, with no DOS-Unix-Batches shit, no makefiles, no linkscripts, etc.

- it has fully working asm/c/c++ & stdlib/memory/stdio support with the ability to retarget all this stuff (useful for embedded systems ;)

- it has a good debugger, with realtime processor emulation

 

All this sounds quite good, so where's the catch?

The problem is that this tool _was not_ specifically written for the gba, so you cant trace your programs with the devkit =( This means that you have to use your old (beta:) debugger!

Anyway, it seems that the AXD debugger has some kind of dll support, so maybe one may write an interface between the devkit and the debugger? (hint,hint) =) I was also told that the guys from ARM are possibly working on this.

 

I just wanted share this with you, as i think this may a better (modern) solution than gcc, so lemme know your impressions!

 

You can order a free evaluation CD on this page: http://www.arm.com/sitearchitek/devtools.ns4/html/dev_tools?OpenDocument&style=Dev_Tools

 

(/Msg me if you need any tips on compiling, it needs some small tweaking)

 

 

PS: You should also take a look at the Applications Library CD, it has a lot of good (optimized) stuff in it like jpeg/mp3/dct... routines (it may be useful, who knows? ;)

 

NOTE: Im not connected to ARM Limited in any way, everything in this mail are my own opinions. =D

 

----------------------------------------------------------

Alexandre GANEA - R & D Departement

Planet Interactive Developement

mailto:aganea@...

----------------------------------------------------------

 

unsubscribe: gbadev-unsubscribe@egroups.com

> ok, lets get this straight, you say Mbit suggesting Mega bits, not bytes,
> this is often confusing, surely Mb (Mega Bits) would be eight times smaller
> than MB MegaBytes, am i right???

exactly