Joey Chang wrote:

>As a newbie programmer who's really interested in doing game boy
>development, I was wondering what people felt were great/preferable
>development platforms and tools for GBA development.  Emulators,
>debuggers, combinations thereof, I'd love to hear what people are
>using and why they feel it works well.  Also, what OS is preferred
>specifically for gba development and why?  Admittedly, I don't know
>much about setting up a Linux box but if it's worth it for gba dev,
>I'll learn.  I know things aren't cut and dry in terms of what's
>better, but it'd be cool to hear what people have to say.  I don't
>mean to start a heated debate, so I welcome input directly to my
>email if you'd rather not post to the forum.  People have been very
>helpful so far and I appreciate it.
>
I use Visual Studio .NET with custom macros that generate a GNU Makefile.
It's the world's must customizable editor, and most importantly it has
tab-completion for variable and function names.

Cheers,
-Pete

Lawrence Oluyede wrote:

>I'm a newbie in GBA dev and I wanna choose the right tool for me.
>Ham, that is simple and full-of-macros or the Devkit, that is not so simple
>and without
>any kind of macros?
>
>
Devkit has better support.  I sent an e-mail to the HAM guy, and (to
date) I never received a response.  In contrast, the devkit guys
responded fairly quickly.  On the downside, Devkit is missing the handy
libraries provided by HAM.  But for "real games", this is probably less
than 5% of your actual code base.

Cheers,
-Pete

I found some bugs in goldroad and sent them to the author.  I haven't
heard a peep in response.  Particularly, improper instructions were
being assembled in thumb mode for some mnemnonics.  In most respects the
assembler is a very nice piece of work.

I have one other gripe with it, that it uses C-style preprocessor
instead of an assembler-style one.  This has, according to the docs, a
bad side effect:

MYSTRUCT equ 0
MYMEMBER equ MYSTRUCT
MYMEMBER2 equ MYMEMBER+4
MYSTRUCTSIZE equ MYMEMBER2+4

Doesn't work

There's also a problem with certain expressions that cause the assembler
to generate invalid instructions.  Particularly negative numbers that he
doesn't mask to the proper bitfield size and then just ORs into the
instruction/opcode.

I didn't do a very thorough evaluation of the assembler - only the thumb
aspect of it, which appears to be an afterthought.

I'm also not trying to diss the software, as it's incredibly valuable
and a wonderful contribution to the developer community.  I just thought
I'd let you know about these things I found before you get too far into
a project and get bit by a bug that you cannot figure out by looking at
your source code :)

=> -----Original Message-----
=> From: Henrik Rydgard [mailto:meloditronic@...]
=> Sent: Wednesday, October 02, 2002 6:46 AM
=> To: gbadev@yahoogroups.com
=> Subject: SV: [gbadev] ARM versus Thumb (now: free macro assembler)
=>
=>
=> So you want a free macro assembler for ARM?
=> www.goldroad.co.uk
=> very nice one it seems..
=>
=> -henrik
=>
=> -----Ursprungligt meddelande-----
=> Fran: Dave Murphy [mailto:wintermute2002@...]
=> Skickat: den 1 oktober 2002 23:05
=> Till: gbadev@yahoogroups.com
=> Amne: [gbadev] ARM versus Thumb
=>
=>
=>
=> Does anyone have any thoughts on the
=> advantages/disadvantages of ARM code versus THUMB code?
=>
=> It seems to be generally accepted that Thumb is more
=> efficient from ROM & ARM is more efficient from internal
=> RAM. I haven't really tested much other than GCC compiled
=> Thumb code is plenty fast enough for sprite based 2d games &
=> going 100% assembly in either mode really isn't worth the
=> hassle for simple code. It seems obvious that using ARM in
=> internal RAM for rasterising code should be the way to go.
=>
=> Has anyone tested the efficiency of hand optimised code for
=> both modes in internal RAM?
=>
=> Personally I prefer assembly to high level languages but I
=> haven't yet found a decent macro assember for ARM that
=> doesn't cost big bucks. Keeping an eye on the assembly
=> output of GCC seems to be the best way of optimising code &
=> learning how to get the compiler to do what you want.
=>
=> Dave

> SFBB.elf: crt0.o crtbegin.o crtend.o main.o background.o board.o
> console.o piece.o sprite.o $(GFXFILES)
>  ld -o SFBB.elf crt0.o crtbegin.o crtend.o main.o background.o
> board.o console.o piece.o sprite.o $(GFXFILES) $(LDFLAGS)

> undef refs to abort, malloc, atexit in
> /libgcc.a(__main.o): In function `__do_global_ctors':
> /libgcc.a(unwind-dw2-fde.o): In function `size_of_encoded_value':
> and others, plus;
> Warning: XXX.o does not support interworking, whereas SFBB.elf does
> for all of my .o files

Suggestion from Jeff nailed the prolem on this. For the benefit of
the archives, ld on the second line of the linker rule changed to gcc
i.e.

SFBB.elf: crt0.o crtbegin.o crtend.o main.o background.o ...
	 gcc -o SFBB.elf crt0.o crtbegin.o crtend.o main.o ...

Here are the relevant lines from my makefile:

CFLAGS = $(IncPath) -mthumb -mthumb-interwork -c -g $(OPTFLAG) -Wall
-fverbose-asm
SFLAGS = $(IncPath) -mthumb-interwork
LDFLAGS = $(LibPath) -T LinkScript -Map $(addsuffix .map,$(basename $@))
StdLibs := -lstdc++ -lgcc -lc
LibObjs := crt0.o crtbegin.o crtend.o

$(BuildDir)/$(PROJECT).elf : $(ObjFiles) $(BinFiles)
     ld $(LDFLAGS) -o $@ $(LibObjs) $^ -lgba $(StdLibs)

The "$^" token takes all the files listed in the dependencies and puts them
there.
$(ObjFiles) are all the files that got compiled.  $(BinFiles) are the binary
files
that were converted to .o files.

LibObjs actually has the full paths to the three files. My makefile is actually
a parameterized one
that I include in other makefiles, so there are a lot more macros than what I've
shown.  I've expanded
a few of them manually for clarity.

I think you're confusing "std lib" with libc, the C runtime lib. I looked at the
symbols in libg.a. This includes
things like printf, atoi, fopen--the standard C library--as opposed to the C
runtime lib, libc.a that includes
things like malloc, memcopy, etc.

So your statment:
> I've read that the linker flags should be set so that c++ lib, then
> the std lib, then the gcc lib should be linked in that order:
would translate to:

-lstdc++ -lg -lgcc -lc

- John
From: "j_north2002" <johnny_north@...>


> I've read that the linker flags should be set so that c++ lib, then
> the std lib, then the gcc lib should be linked in that order:
> LDFLAGS = -L $(LIBDIR) -L $(LIBDIR2) -T lnkscript -lg -lc -lgcc
>
> Now I get:
>
> undef refs to abort, malloc, atexit in

So you want a free macro assembler for ARM?
www.goldroad.co.uk
very nice one it seems..

-henrik

-----Ursprungligt meddelande-----
Fran: Dave Murphy [mailto:wintermute2002@...]
Skickat: den 1 oktober 2002 23:05
Till: gbadev@yahoogroups.com
Amne: [gbadev] ARM versus Thumb



Does anyone have any thoughts on the advantages/disadvantages of ARM code
versus THUMB code?

It seems to be generally accepted that Thumb is more efficient from ROM &
ARM is more efficient from internal RAM. I haven't really tested much other
than GCC compiled Thumb code is plenty fast enough for sprite based 2d games
& going 100% assembly in either mode really isn't worth the hassle for
simple code. It seems obvious that using ARM in internal RAM for rasterising
code should be the way to go.

Has anyone tested the efficiency of hand optimised code for both modes in
internal RAM?

Personally I prefer assembly to high level languages but I haven't yet found
a decent macro assember for ARM that doesn't cost big bucks. Keeping an eye
on the assembly output of GCC seems to be the best way of optimising code &
learning how to get the compiler to do what you want.

Dave







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

--- In gbadev@y..., "Stuart McVicar" <smcvicar@t...> wrote:
> LD is trying to include the file SFBB.elf as if it were an object
file.
> The -o signifies the name of the destination file. if you leave -o
off I think it will try and output to a.out
> So "-o SFBB.elf" is what you want.

I made the suggested change:

SFBB.elf: crt0.o crtbegin.o crtend.o main.o background.o board.o
console.o piece.o sprite.o $(GFXFILES)
	 ld -o SFBB.elf crt0.o crtbegin.o crtend.o main.o background.o
board.o console.o piece.o sprite.o $(GFXFILES) $(LDFLAGS)

I've read that the linker flags should be set so that c++ lib, then
the std lib, then the gcc lib should be linked in that order:
LDFLAGS = -L $(LIBDIR) -L $(LIBDIR2) -T lnkscript -lg -lc -lgcc

Now I get:

undef refs to abort, malloc, atexit in
/libgcc.a(__main.o): In function `__do_global_ctors':
/libgcc.a(unwind-dw2-fde.o): In function `size_of_encoded_value':
and others, plus;
Warning: XXX.o does not support interworking, whereas SFBB.elf does
for all of my .o files

> > GCC compiled Thumb code is plenty fast enough for sprite based
> > 2d games
>
> Even when you have over 100 sprites on the screen?  That's very
> plausible in a space shooter or a Smash TV style game.
> Is 200,000 cycles enough?

yes, it is ... ;-)

cheers,
Markus

According to yerricde (Wed, 02 Oct 2002 00:29:44 -0000):
> That, and for the audio mixer.

True !

> The biggest problem with putting code in IWRAM is that the most
> common link scripts and libraries (such as the ones included with
> devkitadv and HAM) do not directly support the IWRAM code overlay
> trick used in most games for the Atari Jaguar console.  Such
> overlays let you copy a program segment into IWRAM using DMA,
> which means that you don't waste memory by having the T&L code,
> the rasterizer, and the mixer in IWRAM all at once.

*ahem* I've been trying to do overlays with SDT 2.5 but couldn't succeed.
I've read the ADS docs but it seems that the possibility to do overlays
has disappeared.

Could anyone explain how to do overlays with SDT/ADS and/or provide some
examples ?

Thanks forever...

--
     Greg           "Premature optimization is the root of all evil."
                                                  - Anders Gustafsson

----- Original Message -----
From: "yerricde" <d_yerrick@...>

> > Keeping an eye on the assembly output of GCC seems to be the
> > best way of optimising code & learning how to get the compiler
> > to do what you want.
>
> I can attest to that.  It's how I (half-)optimized my mixer.

unfortunately, i can sort of agree.  this *isn't* how you're supposed
to optimize code, but it seems sometimes you can rearrange the
statements in your inner-loop and have gcc optimize things better or
worse.  yuk-- this is what optimizing compilers were *supposed* to
solve.

additionally, if you let gcc generate assembly from your source
('--save-temps'), it seems to be optimizing for some variant of the
arm processor that has some kind of strange pentium-esque instruction
pairing or sequencing.  i found the code generated for the arm target,
while not entirely sub-optimal, was very difficult to follow when i
was first learning the ins-and-outs of arm asm.

this may, of course, have changed since the gcc toolchain that i am
using (2.95.2), but i'm not sure.  i tried building gcc 3.0-3.2, but
there are very serious errors in the thumb compiler (it using sp as a
base register with offsets in thumb instructions sticks out in my
mind) that i could not work around with any degree of reliability, for
me to consider it a useful upgrade.

bleh,
matthew.

> -----Original Message-----
> From: yerricde [mailto:d_yerrick@...]

> > GCC compiled Thumb code is plenty fast enough for sprite based
> > 2d games
>
> Even when you have over 100 sprites on the screen?  That's very
> plausible in a space shooter or a Smash TV style game.
> Is 200,000 cycles enough?

depends on your update code to be honest. Hardware sprites don't use mush in
the way of CPU time :)
the main problem you have is collision since that needs to be done in
software & there are tricks to reduce what actually needs checked.

I was very surprised when I had a basic shell of a game going with around
300 moving objects but that was using tilebased collision. Compiled for
thumb too, thus my comment above.

> The biggest problem with putting code in IWRAM is that the most
> common link scripts and libraries (such as the ones included with
> devkitadv and HAM) do not directly support the IWRAM code overlay
> trick used in most games for the Atari Jaguar console.  Such
> overlays let you copy a program segment into IWRAM using DMA,
> which means that you don't waste memory by having the T&L code,
> the rasterizer, and the mixer in IWRAM all at once.

heh, that sort of stuff can be hand coded quite easily. I was involved in a
Jaguar project once - unfortunately Atari went belly up before they paid us
or the game got published. Pity really as it had been classed AAA by Atari
US :/ We went 100% assembly for that - too much hassle coding for
multiprocessor machines in C methinks. That & we were using Falcons to code
on :) Nice machine with some very odd features the Jag.


> > Personally I prefer assembly to high level languages but I
> > haven't yet found a decent macro assember for ARM that doesn't
> > cost big bucks.
>
> What's wrong with GNU Binutils?

um do you mean GAS? Haven't really looked at it much - got put off by the
horrendous syntax when I was coding 68k & Devpac could output GCC object
files anyway :) Is it any better for ARM?

Looks like the ARM tools are desirable given the dhrystone tests, pity about
the price :/

> > Keeping an eye on the assembly output of GCC seems to be the
> > best way of optimising code & learning how to get the compiler
> > to do what you want.
>
> I can attest to that.  It's how I (half-)optimized my mixer.

heh, chuck the assembly output into a source file & go from there :) There
are tricks in assembly that you just can't code in C, not enough control
over the code. Not that I want to start a C vs Assembly debate - horses for
courses & all that.

Dave

LD is trying to include the file SFBB.elf as if it were an object file.
The -o signifies the name of the destination file. if you leave -o off I think
it will try and output to a.out
So "-o SFBB.elf" is what you want.


> -----Original Message-----
> From: j_north2002 [mailto:johnny_north@...]
> Sent: Wednesday, 2 October 2002 12:28 PM
> To: gbadev@yahoogroups.com
> Subject: [gbadev] Re: c++ make file
>
>
> At the risk of being overindulgent here... I seem to have gotten rid
> of the undef refs by placing the linker flags at the end of the
> linked files list along w/-o. Now with the following, I get:
>
> /cygdrive/c/GBA/BIN/ld: cannot open SFBB.elf: No such file or
> directory
> NMAKE : fatal error U1077: 'c:\GBA\BIN\ld.exe' : return code '0x1'
>
> I know I must have something incorrect in the linker statement line.
> Any sugestions?
>
> GCCARM  = C:GBA\bin
> LIBDIR  = C:\GBA\lib\gcc-lib\arm-agb-elf\3.0.2\interwork
> LIBDIR2 = C:\GBA\arm-agb-elf\lib\interwork
> INCDIR  = C:\GBA\lib\gcc-lib\arm-agb-elf\3.0.2\include
> INCDIR2 = C:\GBA\arm-agb-elf\include
>
> CFLAGS  = -I $(INCDIR2) -I $(INCDIR) -I $(PRJDIR) -mthumb-interwork -
> c -g -O2 -Wall -fverbose-asm
> SFLAGS  = -I $(INCDIR2) -I $(INCDIR) -mthumb-interwork
> LDFLAGS = -L $(LIBDIR) -L $(LIBDIR2)  -T lnkscript -lg -lc -lgcc
>
> #GFXFILES = all of the .o gfx files
>
> all: SFBB.bin
>
> SFBB.bin: SFBB.elf
>  objcopy -O binary SFBB.elf SFBB.bin
>
> SFBB.elf: crt0.o crtbegin.o crtend.o main.o background.o board.o
> console.o piece.o sprite.o $(GFXFILES)
>  ld SFBB.elf crt0.o crtbegin.o crtend.o main.o background.o
> board.o console.o piece.o sprite.o $(GFXFILES) -o $(LDFLAGS)
>
> crt0.o: crt0.s
>  as $(SFLAGS) -o crt0.s
> main.o: main.cpp
>  gcc $(CFLAGS) main.cpp
>
> #I define the compiles of the rest of the cpp compiles from here

At the risk of being overindulgent here... I seem to have gotten rid
of the undef refs by placing the linker flags at the end of the
linked files list along w/-o. Now with the following, I get:

/cygdrive/c/GBA/BIN/ld: cannot open SFBB.elf: No such file or
directory
NMAKE : fatal error U1077: 'c:\GBA\BIN\ld.exe' : return code '0x1'

I know I must have something incorrect in the linker statement line.
Any sugestions?

GCCARM  = C:GBA\bin
LIBDIR  = C:\GBA\lib\gcc-lib\arm-agb-elf\3.0.2\interwork
LIBDIR2 = C:\GBA\arm-agb-elf\lib\interwork
INCDIR  = C:\GBA\lib\gcc-lib\arm-agb-elf\3.0.2\include
INCDIR2 = C:\GBA\arm-agb-elf\include

CFLAGS  = -I $(INCDIR2) -I $(INCDIR) -I $(PRJDIR) -mthumb-interwork -
c -g -O2 -Wall -fverbose-asm
SFLAGS  = -I $(INCDIR2) -I $(INCDIR) -mthumb-interwork
LDFLAGS = -L $(LIBDIR) -L $(LIBDIR2)  -T lnkscript -lg -lc -lgcc

#GFXFILES = all of the .o gfx files

all: SFBB.bin

SFBB.bin: SFBB.elf
	 objcopy -O binary SFBB.elf SFBB.bin

SFBB.elf: crt0.o crtbegin.o crtend.o main.o background.o board.o
console.o piece.o sprite.o $(GFXFILES)
	 ld SFBB.elf crt0.o crtbegin.o crtend.o main.o background.o
board.o console.o piece.o sprite.o $(GFXFILES) -o $(LDFLAGS)

crt0.o: crt0.s
	 as $(SFLAGS) -o crt0.s
main.o: main.cpp
	 gcc $(CFLAGS) main.cpp

#I define the compiles of the rest of the cpp compiles from here

Hi Dave,

> Does anyone have any thoughts on the advantages/disadvantages of ARM code
> versus THUMB code?

THUMB in ROM: Smaller, saves precious IWRAM.
ARM in IWRAM: Generally about 4x faster than thumb in ROM.

Putting ARM anywhere but IWRAM isn't a good idea as it'll be slower than
THUMB. Generally speaking, you should put short, speed-critical code in
IWRAM as ARM and longer, less repetitive code in ROM as THUMB. Well
written ARM code in IWRAM will always be faster than well written THUMB
code in IWRAM because it takes less instructions to achieve the same
results. (And, unlike the rest of the GBA's memory, IWRAM has a 32-bit
bus so the bigger instruction size doesn't decrease performance.)
--
Cheers,
James.

     /\  apex                                 James Daniels
    //\\  designs            james.daniels@...
   //__\\                       http://www.apex-designs.net

--- In gbadev@y..., "Dave Murphy" <wintermute2002@n...> wrote:
>
> Does anyone have any thoughts on the advantages/disadvantages
> of ARM code versus THUMB code?
>
> It seems to be generally accepted that Thumb is more efficient
> from ROM & ARM is more efficient from internal RAM.

Thumb is also more efficient from EWRAM.  Code running from EWRAM
drains the battery much more slowly slower than code running from
ROM, even though it does run slightly slower.

> GCC compiled Thumb code is plenty fast enough for sprite based
> 2d games

Even when you have over 100 sprites on the screen?  That's very
plausible in a space shooter or a Smash TV style game.
Is 200,000 cycles enough?

> It seems obvious that using ARM in internal RAM for rasterising
> code should be the way to go.

That, and for the audio mixer.

The biggest problem with putting code in IWRAM is that the most
common link scripts and libraries (such as the ones included with
devkitadv and HAM) do not directly support the IWRAM code overlay
trick used in most games for the Atari Jaguar console.  Such
overlays let you copy a program segment into IWRAM using DMA,
which means that you don't waste memory by having the T&L code,
the rasterizer, and the mixer in IWRAM all at once.

> Has anyone tested the efficiency of hand optimised code
> for both modes in internal RAM?

Perhaps not hand-optimized code, but compiled code:
http://www.dwelch.com/gba/dhry.htm
ARM code runs about 60% faster from memory without wait states.

> Personally I prefer assembly to high level languages but I
> haven't yet found a decent macro assember for ARM that doesn't
> cost big bucks.

What's wrong with GNU Binutils?

> Keeping an eye on the assembly output of GCC seems to be the
> best way of optimising code & learning how to get the compiler
> to do what you want.

I can attest to that.  It's how I (half-)optimized my mixer.

--
Damian

From: "j_north2002" <johnny_north@...>

> I've now rearranged it to this:
> LDFLAGS = -L $(LIBDIR) -L $(LIBDIR2) -T lnkscript -lstdc++ -lgcc -lc
>
> same errors

So another theory goes up in smoke :(

> do you mean - add -mthumb to the CPPFLAGS options?
> CPPFLAGS  = -I $(INCDIR2) -I $(INCDIR) -I $(PRJDIR) -mthumb-
> interwork -mthumb -c -g -O2 -Wall -fverbose-asm

Well, almost.  What you have listed there as CPPFLAGS should actually
be CFLAGS.  CPPFLAGS, although seemlingly for C++ processing,
actually stands for CPreProcessorFLAGS.  With that change, yes,
-mthumb tells the compiler to generate Thumb code and -mthumb-interwork
tells it to make it able to call, and be called by, ARM code.  You also need
-mthumb-interwork (by itself) when compiling ARM code if you expect to
link with Thumb code.

- John

Hi All...

Is anyone using a DevKitAdv based on GCC 3.2 with the lnkscript and
crt0.S from devrs.com?  Or the gba.x and crt0.S from Dark Fader's
MyLib?  Here's the relevant background information:

I have a nearly completed game written in C++ using DevKitAdv (based
on GCC 3.0.2).  Its working pretty well, but I'd really like to
upgrade to GCC 3.2 because of the better C++ code it produces.  This
group pointed me to Thomas Maniero's DevKitAdv/GCC3.2 binaries at
http://digilander.libero.it/funnybits/devkitadv.html.  These binaries
were a great help, but I'm still having some problems.

I'm using gba.x and crt0.S that came with Dark Fader's MyLib.
They're based on the crtls.zip from devrs.com (which I've also tried,
with no luck).  The first problem I ran into when using GCC 3.2 was a
linker error:

section .iwram [08185738 -> 08187a13] overlaps
section .gcc_except_table [08183c18 -> 0818575b]

I eventually tracked this down to the fact that GCC 3.2 is apparently
adding 3 new sections that were not created by GCC
3.0.2: .init, .fini, and .jcr.  Once I added these to the link script
and included them in the LMA calculations, I was able to link
sucessfully.  Unfortunately, the two emulators I've tried (VisualBoy
Advance and Mappy) both choke on this exectuable.  I simply get a
blank white screen.  The same application built using GCC 3.0.2 works
just fine.  Since I know next to nothing about link scripts (the
changes I made to get it to link were merely guesses) I'm fairly
confident in saying that my link script is somehow causing the
problem.

I'd be happy to post my link script or a sample application if anyone
thinks it might help.  But mostly I'm hoping that someone here is
using Thomas Maniero's version of DevKitAdv (or another version based
on GCC 3.2) successfully with a link script and crt0.s similar to
those in devrs.com's crtls.zip or Dark Fader's MyLib.  If so, I'd
love to see your link script!

Thanks!
Kevin

Hi Chris,

  > PS. Those screenshots are very impressive. Is the engine flexible
  > enough to allow a first-person view?

Theoretically, although the number of visible polygons would be enormous
because it's really optimised for an overhead viewpoint.

By the way, some movies are now available advancegb.com:

http://www.advancegb.com/news/EpFFuVEVupFpTsszJa.shtml
--
Cheers,
James.

     /\  apex                                 James Daniels
    //\\  designs            james.daniels@...
   //__\\                       http://www.apex-designs.net

Does anyone have any thoughts on the advantages/disadvantages of ARM code
versus THUMB code?

It seems to be generally accepted that Thumb is more efficient from ROM &
ARM is more efficient from internal RAM. I haven't really tested much other
than GCC compiled Thumb code is plenty fast enough for sprite based 2d games
& going 100% assembly in either mode really isn't worth the hassle for
simple code. It seems obvious that using ARM in internal RAM for rasterising
code should be the way to go.

Has anyone tested the efficiency of hand optimised code for both modes in
internal RAM?

Personally I prefer assembly to high level languages but I haven't yet found
a decent macro assember for ARM that doesn't cost big bucks. Keeping an eye
on the assembly output of GCC seems to be the best way of optimising code &
learning how to get the compiler to do what you want.

Dave

hi,

I read:
> Dear CK, I can assure you that Aurora is in no way based on gnokki.
> Everything has been written from scratch and nothing has been disassembled
> or reverseengineered.Also there will be developer version available for
> download when the projects gets shaped.

ok ok, calm down young[1] man, I didn't mean to insult you (well maybe a little)
it's just that I think as an _indie_ community we could avoid a lot of "re-
inventing-the-wheel" if people would be more willing to share even incomplete
solutions.

I do all my work on linux/bsd and thus clearly see the advantages of open
projects in my everyday experience even I can occasionally contribute a
fix to otherwise excellent products that come completely with sources (from
which in turn a lot of inspiration and knowledge can be gathered sometimes).

I don't have to pay for software, I don't make big bucks writing it, I'm
not under any sort of NDA, I directly gain _lots_ out of the OS community,
so I kind of feel obliged to occasionally give something back in return
(if the code isn't too embarrassing ;)

OTOH I know that most of the people on this list are using windos and so
the ideas expressed above might seem a bit strange to some of you (after
all you _had to_ either pay or break the law/EULA to use some of your
tools).

sorry to waste the bandwidth,

regards,

x

[1] saw the .jpg

--
chris@... Postmodernism is german romanticism with better
http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)

--- In gbadev@y..., "John Seghers" <johnse@s...> wrote:
> My library inclusions are: -lstdc++ -lgcc -lc
> Order is important on library inclusions unless you use the -( -)
grouping
> arguments.  I know that memcpy and sprintf would be in libc, so if
they
> are being pulled in by libgcc, libstdc++ or libsupc++, that would
be a problem
> with your current commands.

I've now rearranged it to this:
LDFLAGS = -L $(LIBDIR) -L $(LIBDIR2) -T lnkscript -lstdc++ -lgcc -lc

same errors
> I'm also curious... you use -mthumb-interwork, but you are not
specifying
> -mthumb for your c/c++ compilation.  This will set the interwork
flag, but
> compile ARM.  (OK to do, just not sure it's what you wanted.)

I'm really ignorant about most of it, and I've just using options
I've seen in examples; just trying to get it to work while learning.

do you mean - add -mthumb to the CPPFLAGS options?
CPPFLAGS  = -I $(INCDIR2) -I $(INCDIR) -I $(PRJDIR) -mthumb-
interwork -mthumb -c -g -O2 -Wall -fverbose-asm

My library inclusions are: -lstdc++ -lgcc -lc
Order is important on library inclusions unless you use the -( -) grouping
arguments.  I know that memcpy and sprintf would be in libc, so if they
are being pulled in by libgcc, libstdc++ or libsupc++, that would be a problem
with your current commands.

I'm also curious... you use -mthumb-interwork, but you are not specifying
-mthumb for your c/c++ compilation.  This will set the interwork flag, but
compile ARM.  (OK to do, just not sure it's what you wanted.)

- John
From: "j_north2002" <johnny_north@...>

> CPPFLAGS  = -I $(INCDIR2) -I $(INCDIR) -I $(PRJDIR) -mthumb-
> interwork -c -g -O2 -Wall -fverbose-asm
> SFLAGS  = -I $(INCDIR2) -I $(INCDIR) -mthumb-interwork
> LDFLAGS = -L $(LIBDIR) -L $(LIBDIR2) -T lnkscript -lg -lc -lgcc -
> lstdc++ -lsupc++
>
> still get:
> undef ref to __gccmain - memcpy - sprintf

> I've tried adding this option in; trying before and after all of
the
> other options. I'm getting the same errors. Any other suggestions?

These are my options right now: maybe the paths are incorrect?

LIBDIR  = C:\GBA\lib\gcc-lib\arm-agb-elf\3.0.2\interwork
LIBDIR2 = C:\GBA\arm-agb-elf\lib\interwork
INCDIR  = C:\GBA\lib\gcc-lib\arm-agb-elf\3.0.2\include
INCDIR2 = C:\GBA\arm-agb-elf\include

CPPFLAGS  = -I $(INCDIR2) -I $(INCDIR) -I $(PRJDIR) -mthumb-
interwork -c -g -O2 -Wall -fverbose-asm
SFLAGS  = -I $(INCDIR2) -I $(INCDIR) -mthumb-interwork
LDFLAGS = -L $(LIBDIR) -L $(LIBDIR2) -T lnkscript -lg -lc -lgcc -
lstdc++ -lsupc++

still get:
undef ref to __gccmain - memcpy - sprintf

--- In gbadev@y..., "Stuart McVicar" <smcvicar@t...> wrote:
> try adding -lstdc++
>
I've tried adding this option in; trying before and after all of the
other options. I'm getting the same errors. Any other suggestions?

--- In gbadev@y..., CK <x@m...> wrote:
> I read:
> > not knocking it if it works, but why keep it so secret, I'm sure there are a
>
> maybe because a disassembled rom will look a lot like gnokii or some other
> gnuish mobile driver compiled for arm ;)
>
> I've been tinkering a bit with siemens mobile<->gba, scmxx has all the info
> if I find the time to get it to a useful stage I'll release it gpled.
>
> cheers
>
> x
>
> --
> chris@l... Postmodernism is german romanticism with better
> http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)

Dear CK, I can assure you that Aurora is in no way based on gnokki.Everything
has been written from scratch and nothing has been disassembled or
reverseengineered.Also there will be developer version available for download
when the projects gets shaped.    With best regards, Peter "ph0x" Moraliyski

I would just use VBA -- it's not open source, but, IMO, it's the best GBA
emulator out there.  With the latest releases, it's even rivaling Mappy for
debug support.

dennis

-----Original Message-----
From: Luke-Jr [mailto:luke7jr@...]
Sent: Monday, September 30, 2002 9:55 PM
To: gbadev@yahoogroups.com
Subject: [gbadev] Linux tools


I'm about to get back into GBA development... My PC is 100% Linux...
DevKit Advance sounds good for a compiler set, but I can't seem to find
a nice open source emulator for Linux... Can anyone recommend one? (mods
feel free to reject msg w/ an answer if u know one)

I read:
> a nice open source emulator for Linux... Can anyone recommend one? (mods
> feel free to reject msg w/ an answer if u know one)

boycott advance runs just fine under linux, not opensource though AFAIK
you also might give wine a shot, some of the tools that deserve to be
kept secret to avoid other people adding features to them (or because
they were done in vb ;) run just fine with it (including goldroad)

regards,

x

--
chris@... Postmodernism is german romanticism with better
http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 01 Oct 2002 2:54 am, Luke-Jr wrote:
> I'm about to get back into GBA development... My PC is 100% Linux...
> DevKit Advance sounds good for a compiler set, but I can't seem to find
> a nice open source emulator for Linux... Can anyone recommend one? (mods
> feel free to reject msg w/ an answer if u know one)

Visualboy advance, easily the best emulator for the GBA.

Tom

- --
Email: tb100@... || Jabber: tombadran@...
Homepage:   http://www.doc.ic.ac.uk/~tb100
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE9mTY1XCpWOla2mCcRArNdAKC8gr3QQ7tpp8j9ES6LgrZU08p41ACeI8P2
9SAAjXI7vATKGzFUhOgUDs8=
=Zud3
-----END PGP SIGNATURE-----

try adding -lstdc++

> -----Original Message-----
> From: j_north2002 [mailto:johnny_north@...]
> Sent: Tuesday, 1 October 2002 1:10 PM
> To: gbadev@yahoogroups.com
> Subject: [gbadev] c++ make file
>
>
> I'm trying to figure out the correct way to write a make for MSVC,
> but I keep getting the following:
>
> undefined reference to `__gccmain'
> undefined reference to `memset'
> undefined reference to `rand'
> undefined reference to `sprintf'
>
> jeff's FAQ suggests that I may not be linking libgcc correctly, but
> my linker options look like this:
>
> LDFLAGS = -L $(LIBDIR) -L $(LIBDIR2) -T LnkScript -lg -lc -lgcc
>
> can someone help me out here?
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Sell a Home for Top $
> http://us.click.yahoo.com/RrPZMC/jTmEAA/MVfIAA/cPRolB/TM
> --------------------------------------------------------------
> -------~->
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>

I'm about to get back into GBA development... My PC is 100% Linux...
DevKit Advance sounds good for a compiler set, but I can't seem to find
a nice open source emulator for Linux... Can anyone recommend one? (mods
feel free to reject msg w/ an answer if u know one)