all arm instructions MUST be word aligned (32bit)
   all thumb must be (halfword) 16bit aligned.
   all word reads MUST be word aligned
   partly 'cos its a RISC CPU, and partly becuase bit 0 is used by the bx
   instruction to
   tell if its going to thumb or arm, (0==arm, 1==thumb)

   if you do not know the alignment
   then to goto thumb you have to set the bottom bit of the address.
   the address of any function will always have this bit clear

   if your going to thumb to arm
   .extern DivR0byR1
   .align 4
   DivR0byR1Address:
   .word DivR0byR1
   ......

Yep, I just got the Arm/Thumb reference cards and other documents about it. 
I've got the reference from rE Ejected, too, though that isn't too helpful for
some things.

The last bit makes sense, yes.

But, someone else already answered this question, so I'll post the answer here:

http://www.devrs.com/gba/files/gbadevfaqs.php#EmptyBits

It's due to the IWram not being copied with the '.section .iwram' declaration. 
It needed:

   .section .iwram,"ax",%progbits

To find out what this actually means, look at:
http://www.gnu.org/manual/gas-2.9.1/html_mono/as.html#SEC119

Btw, a nice way to halt code is:
  mov lr,#0
  bx lr

Otherwise I might have still been in the dark about what's going on.

Thanks. ^.^

Jason Emery
World Tree Games


[Non-text portions of this message have been removed]

all arm instructions MUST be word aligned (32bit)
all thumb must be (halfword) 16bit aligned.
all word reads MUST be word aligned
partly 'cos its a RISC CPU, and partly becuase bit 0 is used by the bx
instruction to
tell if its going to thumb or arm, (0==arm, 1==thumb)

if you do not know the alignment
then to goto thumb you have to set the bottom bit of the address.
the address of any function will always have this bit clear

if your going to thumb to arm
  .extern DivR0byR1
.align 4
  DivR0byR1Address:
  .word DivR0byR1
......

  ldr r9,  DivR0byR1Address @ divaddress
  mov lr, pc
  bx r9

so if you trying to get to thumb
either
  ldr r9,  DivR0byR1Address @ divaddress
  orr r9,  r9, #1
  mov lr, pc
  bx r9

or
  .extern DivR0byR1
.align 4
  DivR0byR1Address:
  .word DivR0byR1+1

if you read from a 16 bit aligned 32 bit unaligned address the top and
bottom halfwords get swapped (A bit like the 68K used to do)

seek ARM7TDMI Data Sheet 'ARM DDI 0029E'.pdf or
ARM7TDMI_Data_Sheet_'ARM_DDI_0029E'.zip from the web it has it all inside.

Mike.

----- Original Message -----
From: "felix_draconis" <felixd@...>
To: <gbadev@yahoogroups.com>
Sent: Sunday, February 03, 2002 3:46 AM
Subject: [gbadev] Assembly: Address Bug


>
> Hate having to ask questions on this.  I haven't ever had this much
> trouble with assembly code before, even on the GBC, but there's
> something rather daunting about learning the GAS compiler the wrong
> way around - from someone else's completed codebase.
>
> Anyway, I have this piece of code which for all intentions seems like
> it should work, but doesn't...  I've simplified it here down to the
> bare components.
>
> ... part of the 'header' area
> .extern DivR0byR1
> DivR0byR1Address:
> .word DivR0byR1
>
> ... code the call originates from
> ldr r9,  DivR0byR1Address @ divaddress
> mov lr, pc
> bx r9      @ << This crashes
>
> The DivR0byR1 function is in another .s file.  Now, anyone would ask
> whether the function is crashing when executing or coming back, so I
> copied it to this .s file and added the letter 'Z' to the front of
> the function.  No crash.  How is it different using LDR to get the
> address?  Am I running again into the problem of BX needing a
> hardware bit within the value at R9 in order to call the function
> properly (to switch to/from ARM mode)?  Or, granted, it could just be
> a limitation/bug in my compiler.  Wouldn't be the first time.
>
> Thanks ever so much for the previous answers to other questions.
> Seems like this should have just been a snap, but there's always
> something that pops up.  At least I'm being forced on a crash course
> on all sorts of Arm/Thumb assembly.
>
> Jason Emery
> World Tree Games
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

Hate having to ask questions on this.  I haven't ever had this much
trouble with assembly code before, even on the GBC, but there's
something rather daunting about learning the GAS compiler the wrong
way around - from someone else's completed codebase.

Anyway, I have this piece of code which for all intentions seems like
it should work, but doesn't...  I've simplified it here down to the
bare components.

... part of the 'header' area
	 .extern  DivR0byR1
DivR0byR1Address:
	 .word  DivR0byR1

... code the call originates from
	 ldr  r9,  DivR0byR1Address @ divaddress
	 mov  lr, pc
	 bx  r9      @ << This crashes

The DivR0byR1 function is in another .s file.  Now, anyone would ask
whether the function is crashing when executing or coming back, so I
copied it to this .s file and added the letter 'Z' to the front of
the function.  No crash.  How is it different using LDR to get the
address?  Am I running again into the problem of BX needing a
hardware bit within the value at R9 in order to call the function
properly (to switch to/from ARM mode)?  Or, granted, it could just be
a limitation/bug in my compiler.  Wouldn't be the first time.

Thanks ever so much for the previous answers to other questions.
Seems like this should have just been a snap, but there's always
something that pops up.  At least I'm being forced on a crash course
on all sorts of Arm/Thumb assembly.

Jason Emery
World Tree Games

Thanks for the suggestion - Mappy showed that all the data was where
it should have been, but at least it duplicated the problem. I
tracked down what was wrong in the end - I was assuming the sprites
would be numbered from 0, whereas of course in bitmapped modes you
have to start from 512. No idea why VGBA works with the wrong values,
but adding 512 to all my character offsets made everything work on
Mappy and on real hardware too.

You can see the terrifying result at:

http://www.slithy.freeserve.co.uk/monkey.html

:)

iapetus

Hi there,

I had some problems using sprites in mode4 but that was because I was
copying the sprite data to the wrong location - could be that you are
writing the objdata to 0x06010000 rather than 0x06014000 (bit-mapped
modes objdata offset)?  I would suggest running your code on mappy
and see what's happening to the sprite data and OAM entries.

Best wishes Joseph

Check the MBV2 cable.
http://www.devrs.com/gba/files/mbv2faqs.php

Uze/belogic

--- In gbadev@y..., "ToddnMara" <vze3357u@v...> wrote:
> Hi; I'm new to this list.
> I've got a job (probable) that needs input from a serial device
while a gba game is running.  I can program the game and maybe the
comm code but are there any people here who'd like to help in this
project; I'd get money info in a few days.
> Needs a serial cable interface to a serial pic device which has been
created to comm to a pc; we want it to send little bits of data to a
game while the game is running. (standalone game)
> I'm working on the research but welcome someone who wants to work on
it from a hw/sw point of view.
> Cheers hello etc.
> Todd
>
>
> [Non-text portions of this message have been removed]

Hi, i'm a bit lazy to check all your code, but have you got a look at
the Audio Advance at http://www.belogic.com/gba ? It has in dept
explanation of direct sound playback and its registers...and
everything  in there has been tested up to the last bit on the real
hardware!

hope it helps,

Uze/belogic

ps: I'haven't seen any VBL irq enabling in your code, i guess you
didn't show it?

--- In gbadev@y..., defjam_cp@g... wrote:
>
>
> Hello,
>
> I'm trying since some time to get my DirectSound stuff working - on the
> emulators I use everything works fine (BoycottAdv. & VisualBoyAdv.),
but on
> the
> real Hardware nothing works  (I don't have a GBA/flash||mbv2 yet)
>
> Ok.. code says more than 1000 words:
>
[cropped by mod]

Any code that you want to share? :)

I have sprites working in my game, and all it took was some working with the
code over at the PERN project tutorial.

I doesn't sound like a priority issue -- since you're using the default
priority, sprites always have priority over backgrounds with the same
priority.  You could try turning the background off to see if the sprites
suddenly show up.

Did you set the sprite palette?  Did you copy over your OAM data copy to the
real location?  Check the basics first, and then see what happens.

Good Luck!
dennis

-----Original Message-----
From: iapetus_98 [mailto:Adrian.Jackson@...]
Sent: Saturday, February 02, 2002 2:16 PM
To: gbadev@yahoogroups.com
Subject: [gbadev] Invisible sprites...

Has anyone else run into this sort of problem, and are there any
suggestions for what might be causing the problems? First guess is
that it might be some sort of priorities issue.

I've finally got my hands on a flash advance system, so I can get my
programs up and running on real hardware, but I'm finding a few
problems getting things working.

Although my code works fine on VGBA, on the real GBA, none of the
sprites appear to be displayed - other than that the code works fine,
and provided I don't mind using the Force to play the game it's not a
problem. But I can't help thinking it would be easier for those who
aren't Jedi masters to see if I could get them working on the real
thing.

Has anyone else run into this sort of problem, and are there any
suggestions for what might be causing the problems? First guess is
that it might be some sort of priorities issue.

I'm running in mode 4, IIRC (2 buffers, 256-colour background) and
writing directly to OAM to set up the sprites. I've enabled the OBJ
and BG2 in the DISP_CONT and I'm using whatever the default priorities
are for everything - from my reading of what documentation's
available, that *should* make my sprites visible, but no such luck...

Any pointers?

iapetus

Hello,

there is a new release of the SGADE available. Version 0.99 is completely
stable, and all features work on Gameboy Advance hardware now. There have
been some architectural and design chances, and loads of cleaning up. We
have new features like easy DMA transfers, flash memory (SRAM) handling and
loads more. There is a full SGADE reference and documentation available,
which should get you up and running in no time. I've also written some
tutorials, which should make it as easy as possible to start coding
something. Finally, I've started a mailing list for all things SGADE
related. More information on the SGADE website.

So, if you ever wanted to create a game without all the engine and hardware
hassle, you better check out the SGADE at http://jaap.flipcode.com/sgade/.
See you on the mailinglist!

Cheers,

Jape

Jason,
   The problem is that the use of the link register and pc have been
   extended to determine what mode the processor should be in. By mode,
   I mean THUMB or ARM (rather than supervisor etc).

   So if your return address is in the middle of some thumb code and
   your procedure is in ARM, then the processor state must be swapped to
   thumb when you return. As far as I can work out without the docs, the
   command bx changes the processor state depending on the flags in the
   lr. The mov command does not. So basically you need to use bx if
   you're jumping back into some code which you don't know whether it's
   in thumb or arm, or if you KNOW that it's in tumb or arm and your
   procedure is in arm or thumb!

   This means that to do an LDMFD sp!,{r0-r12,pc} or whatever your more
   complicated code is, then you need to do:

   LDMFD sp!,{r0-r12,lr}
   bl lr

   Yes it's silly, but there you go. Hope that helps.
>>

Doh, you're right!  I should have realized that it was switching back and forth,
but I didn't realize the branch instructions altered the CPU state as well. 
Thought that required an explicit command, but then when I think about it
there's really no good alternative to having the state set 'automatically'.

Changing all the "mov pc,lr" instructions helps.  In fact, aside from there not
being any way to test it just yet, most of the code appears to work then.  I
know someone else suggested converting entirely to ARM, but I'd like to avoid
that in case of future problems, though it's an option.

Currently most things appear to work, though I'm wrangling with the main
interrupt which is giving out bad IO instructions.  I wish the code was
documented. :)

If I -do- manage to get it working in -mthumb-interlink mode I should probably
send a version back to the GASS author.  I've tested many of the demos and it
sounds quite nice compared to most of them.

Jason Emery
World Tree Games


[Non-text portions of this message have been removed]

can you compile to an asm file with ADS
like gcc -S  option

if so do that and see what asm instructions you get.

but first I'd check ones that you've used L (ell) not 1 (numeric one) at the
end
with some screen font its hard to tell.

this is obviously not your code because
0x60000 * 0x40000 == 0x1800000000 (eight 0's not six)
my vote is a typo (missing missing x in a hex constant so it appears as an
octal or dec)

if you realy want help post code you've tested and cunt'n'paste it from the
working/none working source, it help people spot the bgs from the typos,
without having to run test code ourselves (I'm lazy that way!)

Mike.
----- Original Message -----
From: "Emil Arkman" <emil_arkman@...>
To: <gbadev@yahoogroups.com>
Sent: Friday, February 01, 2002 7:02 PM
Subject: [gbadev] u64 multiply


> I was going to do a fixed point mul and got strange results from ADS 1.1.
>
> Might be a bad example since the error is not that big, but it's simple
> code:
>
> void func (void)
> {
>      s64 aLong, bLong, cLong;
>     aLong=0x60000ll;
>     bLong=0x40000ll;
>     c=a*b;
>
>     // at this point cLong is 0x18002800 instead of 0x18000000
> }
>
> Anyone know why?
>
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

I was going to do a fixed point mul and got strange results from ADS 1.1.

Might be a bad example since the error is not that big, but it's simple
code:

void func (void)
{
      s64 aLong, bLong, cLong;
     aLong=0x60000ll;
     bLong=0x40000ll;
     c=a*b;

     // at this point cLong is 0x18002800 instead of 0x18000000
}

Anyone know why?

from what I remeber of A level maths,
the dot product of your motion vector and the normal to the line will give
you the angle
between the normal and the motion vector
I can't find my math text book, but its something like
a.b = |a||b|cos(angle) = ax.by - ay.bx
|a| is the lenght of the vector (its modulus) => ax*ax + ay*ay

the vector can then need to be rotated as required remember that the angle
is the angle between the vectors as if the both started at the origin and
measures anticlockwise from a to b (from what I can remeber of vector
maths).

you can of course use the line/motion angle and add/subtract 90 from it.
to get the require rotation.

I'm sure that are are several short cuts, but you now have a basis to start
looking from.

Mike.

----- Original Message -----
From: "Ben Hopkins" <gbtheory@...>
To: <gbadev@yahoogroups.com>
Sent: Friday, February 01, 2002 4:26 PM
Subject: [gbadev] bouncing ballz


> The project Im currently working on requires me to have bouncing ball. I
> know some basic vector math but haven't been able to find how to do what I
> want. Cue -=bad=- ASCII diagram :o)
> OK I have a multisided 2d poly and I want to make a ball bounce
> realistically around the inside of the poly:
>
>                 ________________
>                /                                \
>               /                                  \
>              /                                    \
>             /               O                    \
>             \                                      /
>               \_________________/
>
> So what I need to know is how to calulate the new vector once the ball
> collides with one of the lines. Im guessing it'll have something to do
with
> the normal of each line??
> Thanx in advance :o)
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

The project Im currently working on requires me to have bouncing ball. I
know some basic vector math but haven't been able to find how to do what I
want. Cue -=bad=- ASCII diagram :o)
OK I have a multisided 2d poly and I want to make a ball bounce
realistically around the inside of the poly:

                 ________________
                /                                \
               /                                  \
              /                                    \
             /               O                    \
             \                                      /
               \_________________/

So what I need to know is how to calulate the new vector once the ball
collides with one of the lines. Im guessing it'll have something to do with
the normal of each line??
Thanx in advance :o)

Thank you guys for your answers, I completely forgot about .incbin!

It would also be cool that everyone who answers in this group, reads what ppl
answered before, because I've got the same answer 5 times and counting. That's
something I wanted to say because it happens most of the time with the other
threads and it's quite annoying.

Cheers,
Alex.


[mod note: yes, it is mostly our responsibility to prevent this, and we may need
to improve in that aspect sometimes :]

Ben Smith wrote:
>
> Hi all,
>     I've been trying to compile GASS also, and found that all data that was
supposed to be loaded into IWRAM isn't. What's weirder is that the data isn't
even at the ROM load address.
>     A simple test has shown me that Jeff's lnkscrpt will load data into IWRAM
correctly if there are C constants being loaded also, but incorrectly if the
only external data is loaded through an asm file.

This is due to the way GAS works it appears.
I just added this to the GBA Dev FAQs:

   http://www.devrs.com/gba/files/gbadevfaqs.php#EmptyBits

GAS Assembly FAQs

Q: When I compile assembly code to go into section .iwram, only empty (0x00)
    code is copied from ROM to IWRAM. Why?
A: It is not enough to just do the following:
-.SECTION .iwram
-you need to do the following instead:
-.SECTION .iwram,"ax",%progbits
-or otherwise the code that is put in ROM, to be copied to IWRAM,
-for some reason is composed only of the value 0x00.
-If you use the GCC command line option -save-temps when compiling
-a C file then you will notice similar directives in the resulting .s
-temporary files. Search this file on the keyword 'progbits' for
-other examples.

  Jeff

Lua is my choice, it's fast, small and really powerful.

----- Original Message -----
From: "Mike Wynn" <mike.wynn@...>
To: <gbadev@yahoogroups.com>
Sent: Viernes, 01 de Febrero de 2002 09:26 a.m.
Subject: Re: [gbadev] Lua


> If yuo were going to port a language to GBA for prototyping,
> isn't a langauge like D a better choice ?
> Mike.

"owaincole" <owaincole@...> writes:

> LDMFD sp!,{r0-r12,lr}
> bl lr
you mean "BX LR" right?:)

If yuo were going to port a language to GBA for prototyping,
isn't a langauge like D a better choice ?
Mike.

Jason,
The problem is that the use of the link register and pc have been
extended to determine what mode the processor should be in. By mode,
I mean THUMB or ARM (rather than supervisor etc).

If your processor is in the wrong state and it tries to execute a
command from the wrong instruciton set, then you get all sorts of
problems, Basically it tends to keep on going executing random
instructions since it is doubtfull that you'll have coded a branch by
accident!! - Or until it gets to some code which is in the correct
state... but then that wont help much either!

So if your return address is in the middle of some thumb code and
your procedure is in ARM, then the processor state must be swapped to
thumb when you return. As far as I can work out without the docs, the
command bx changes the processor state depending on the flags in the
lr. The mov command does not. So basically you need to use bx if
you're jumping back into some code which you don't know whether it's
in thumb or arm, or if you KNOW that it's in tumb or arm and your
procedure is in arm or thumb!

This means that to do an LDMFD sp!,{r0-r12,pc} or whatever your more
complicated code is, then you need to do:

LDMFD sp!,{r0-r12,lr}
bl lr

Yes it's silly, but there you go. Hope that helps.
Owain


--- In gbadev@y..., "felix_draconis" <felixd@f...> wrote:
>
> Has anyone managed to get GASS compiling and running and would have
> the time to provide a few answers to questions?
>
> I think I'm pretty close, as everything now links in and compiles
> properly, but it promptly crashes at the instruction:
>
> mov pc,lr
>
> (which I presume is trying to copy the return address for the
> function call to assembly into PC)
>
> (and yes, I can 'fix' it with bx lr, but there are more complex
uses
> of pc later on that I can't seem to correct)
>
> I know there'll likely be other problems, hence why I'm reluctant
to
> ask too many questions of the list.  Searching elsewhere doesn't
seem
> to reveal any tutorials on this, or even what compiler was being
used
> at the time.  I can only imagine what settings
>
> But at the same time, days of constant effort are starting to be
> tiring. ^.^
>
> Jason Emery
> World Tree Games

yo list,

i have been on this list for a while but have just been reading until this
post.

anyway, we are using lua at work since we have wrapped our 3d engine with
lua calls. i have in fact thought of using lua for gba aswell but the
problem is offcourse that in order to do so someone has to make wrapper
functions at C level for all the functionallity one would like to access on
the lua-level. i could do it myself but has definitely not time now and it
might be a great amount of work depending on how much functionallity one
want to add in. Jeff's gfxlib might be a good starting point.

i would really like to see a good lua environment to do gba stuff with.
should be great for making prototyps and such. and i belive that everything
that simplifies development (lua is really easy to get a grip on) for all
non asm gurus out there should benefit the whole comunity in the long run.
well, if anybody doesn't do this now, i might do it later myself. time will
tell.

         /dan

----- Original Message -----
From: "Mike Wynn" <mike.wynn@...>
To: <gbadev@yahoogroups.com>
Sent: Friday, 01 February, 2002 00:45
Subject: Re: [gbadev] Lua


> I doubt it ....
> its a scripting lang, well it's designed to be embedded in a C app, you
> might use it for AI scripts, but as the GBA has no file system they would
be
> hard coded, so you might as well just use C.
>
> its gcc compilable, and from the docs it should be small enought to build
> for gba
> not too sure how exactly you woulds get you script in. I guess you might
> want to experiment with serial comms to upload programs :)
>
> I guess you've been to
> http://www.lua.org
> you can get the source from
> http://www.tecgraf.puc-rio.br/lua/download.html
> (which _should_ compile with the gba gcc)
> and there's an IDE of sorts (designed for embedding Lua in win32 apps)
> http://home.t-online.de/home/KZerbe/edelua.htm
>
> I suspect that you are the only person who has thought about using Lua on
a
> GBA
> Mike.

Hey,
     I just got GASS to compile. Seems as though the GASS example (and
SoundEngine... files) expect the entire file to be running as arm. When I
compiled test.c and SoundEngine.c as arm it works.

     Not too helpful, I know... but it's a start.

Ben

Hi all,
     I've been trying to compile GASS also, and found that all data that was
supposed to be loaded into IWRAM isn't. What's weirder is that the data isn't
even at the ROM load address.
     A simple test has shown me that Jeff's lnkscrpt will load data into IWRAM
correctly if there are C constants being loaded also, but incorrectly if the
only external data is loaded through an asm file. Not a big deal I guess, but it
might be something to fix in the next revision... :)

Ben

here's the test:

asm.s:
     .section .iwram
     .global AsmExternInIWRAM
AsmExternInIWRAM:
     .word 0xDEADC0DE

c.c:
//  const unsigned int CInIWRAM __attribute__ ((section (".iwram")))=
0xDEADC0DE;
// when this is commented Mappy prints 0.
// Uncommented Mappy prints 0xDEADC0DE

test.c:

extern unsigned int AsmExternInIWRAM;
extern const unsigned int CInIWRAM;
extern int __printf(char *, ...);

int AgbMain()
{
     __printf("%x", AsmExternInIWRAM);
     while (1);
     return 0;
}

debug.c:

void dprint(const char *sz)
{
  asm volatile
  (" \
   mov  r2, %0  \n\
   mov  r0, %1  \n\
   mov  r1, #0  \n\
   and  r0, r0, r0  \n\
    "
     : : "r" (sz), "r" (0xC0DED00D) : "r0", "r1", "r2"
  );
}

int __printf(char *fmt, ...)
{
  char s[256];
  va_list marker;
  va_start(marker, fmt);
  int r = vsprintf(s, fmt, marker);
  va_end(marker);
  dprint(s);
  return r;
}




[Non-text portions of this message have been removed]

I'd like to chime in again about adding in binary data files, simply to be
helpful, though this depends on what compiler you're using.

The version of GAS that I've been using does not support .incbin, and I've found
confirmation of this fact online that it's been taken out (WHY??).  Now, another
programmer here is using a custom version of GAS with .incbin added in, but
devkitadv, for instance, doesn't seem to have this.  We've swapped .s files back
and forth to confirm this.

All of my original variables are stored in .h and .c files, so what I've done is
written a fast little conversion routine from a .h array to .s, then converted
that with AS into a .o file.  Then all I have to do is link in the .o file at
build-time.  Very fast!  And more space-efficient.

I found that converting directly to a .o file with ObjCopy, which is recommended
at http://www.devrs.com/gba/files/gbadevfaqs.php#IncRaw doesn't work for me (I
get an error about not having -mthumb-interworking support).  Pity, as devkitadv
comes with a batch file specifically trying to help with this very solution, but
the file it generated wouldn't link in, even after I added the ALIGN 4 statment.

So, this 'brute force' method I've cooked up converts very quickly, as most of
the time appears to be spent in the compiling of .h into a .s file, and might
even circumvent the virtual memory exhausted error I've encountered before
adding the GCC patch.  My conversion proggie has its limitations, like how I
extract one array at a time, but that could be changed, or just lived with. 
It's not a fatal problem by any means.

The jist of this is that .incbin doesn't appear to be supported by GAS often, as
far as I can tell, so other methods need to be used.

Hope this helps!

And again, if anyone wants my conversion program, just let me know.  I've tested
it with huge sprite tables so far, though I'm sure there's other little bugs.

Jason Emery
World Tree Games


[Non-text portions of this message have been removed]

/* Devkit Advance, multiboot, global variables, and malloc()

I've been having problems getting Devkit Advance (a GCC toolchain)
to make working multiboot binaries in some circumstances.
Three specific issues follow:

If I make a large uninitialized global variable, it increases the
size of the binary significantly.

If I make a multiboot program with a global variable in EWRAM, the
program won't run in an emulator nor on hardware.

If I call malloc() from a multiboot program, the memory allocated
overlaps the program's code and data.

*/


/*** begin smiley.c ***/


#include <stdlib.h>


/* excerpts from pin8gba.h, which uses variable names that
    1. make sense to me and 2. aren't official so the big
    N can't touch me */

typedef unsigned short u16;
struct BGPOINT
{
   u16 x, y;
};
typedef u16 NAMETABLE[32][32];

#define RGB(r,g,b) ((r)|(g)<<5|(b)<<10)
#define PALRAM ((u16 *)0x05000000)
#define VRAM   ((u16 *)0x06000000)
#define MAP ((NAMETABLE *)0x06000000)

#define LCDMODE (*(volatile u16 *)0x04000000)
#define LCDMODE_BLANK    0x0080
#define LCDMODE_BG0      0x0100
#define LCD_Y (*(volatile u16 *)0x04000006)  /* 0-159: draw; 160-227
vblank */
#define BGCTRL ((volatile u16 *)0x04000008)
#define BGCTRL_PAT(m)    ((m) << 2)
#define BGCTRL_16C       0x0000
#define BGCTRL_256C      0X0080
#define BGCTRL_NAME(m)   ((m) << 8)
#define BGCTRL_H32       0x0000
#define BGCTRL_H64       0x4000
#define BGCTRL_V32       0x0000
#define BGCTRL_V64       0x8000
#define BGSCROLL ((volatile struct BGPOINT *)0x04000010)

#define IN_EWRAM __attribute__ ((section (".ewram")))
#define IN_IWRAM __attribute__ ((section (".iwram")))
#define CODE_IN_IWRAM __attribute__((section(".iwram"),long_call))



/*** Controls ***/

/* Comment out the following line to make a cartridge image
    as opposed to a multiboot image. */
int __gba_multiboot;

/* Uncomment the following line to make a global variable
    that adds 20 KB to the size of the binary. */
// char blah[20480] IN_IWRAM;

/* Uncomment the following line to make a global variable
    that adds 20 KB to the size of the binary and does not
    run when sent over multiboot. */
// char blah[20480] IN_EWRAM;




/*** Map data ***/

const unsigned short circle_data[16] =
{
   0x07e0,0x1818,0x2004,0x4002,0x4002,0x8001,0x8001,0x8001,
   0x8001,0x8001,0x8001,0x4002,0x4002,0x2004,0x1818,0x07e0
};

const unsigned short smiley_data[16] =
{
   0x07e0,0x1818,0x2004,0x4002,0x4002,0x8c31,0x8c31,0x8001,
   0x8001,0x8811,0x8421,0x43c2,0x4002,0x2004,0x1818,0x07e0
};

const unsigned short frowny_data[16] =
{
   0x07e0,0x1818,0x2004,0x4002,0x4002,0x8c31,0x8c31,0x8001,
   0x8001,0x83c1,0x8421,0x4812,0x4002,0x2004,0x1818,0x07e0
};


void draw_smiley(unsigned int nt, const unsigned short *img_data)
{
   unsigned int x, y;
   /* 1024 u16's in a map, 16 u16's in a 16-color tile;
      therefore a map takes the same space as 64 tiles.
      To save RAM, draw_smiley() uses tiles 62 and 63 to draw the
      black and white blocks. */
   unsigned int base_tile = (nt << 6) | 0x3e;

   /* clear the map */
   for(x = 0; x < 20*32; x++)
     MAP[nt][0][x] = 0x3e3e;

   /* set up tiles 62 and 63 to constant colors 0 and 1 */
   for(x = 62*16; x < 63*16; x++)
     MAP[nt][0][x] = 0x0000;
   for(x = 63*16; x < 64*16; x++)
     MAP[nt][0][x] = 0x1111;

   /* draw map */
   for(y = 0; y < 16; y++)
   {
     int shiftreg = img_data[y];
     for(x = 0; x < 16; x++)
     {
       MAP[nt][y + 2][x + 7] = (shiftreg & 1) | base_tile;
       shiftreg >>= 1;
     }
   }
}


/* helper function to display an integer in binary */
void display_int(unsigned int shiftreg, unsigned int y)
{
   unsigned int bits;

   for(bits = 29; bits > 0; bits--)
   {
     MAP[0][y][bits] = (shiftreg & 1) | 0x3e;
     shiftreg >>= 1;
   }
}


int does_malloc_work(void)
{
   /* This allocates 40 KB of space and _should_ come out of EWRAM. */
   unsigned char *foo = malloc(40960);

   if(!foo)
     return 0;

   /* display pointer using 0 and 1 blocks */
   display_int((unsigned int)foo, 19);

   /* display address of this function
      should display 0x0800xxxx for cart or 0x0200xxxx for multiboot
    */
   display_int((unsigned int)does_malloc_work, 18);


   free(foo);
   return 1;
}


#define MAP_TO_USE 0

int main(void)
{
   LCDMODE = LCDMODE_BLANK;

   draw_smiley(MAP_TO_USE, smiley_data);
   does_malloc_work();

   BGSCROLL[0].x = 0;
   BGSCROLL[0].y = 0;
   BGCTRL[0] = BGCTRL_PAT(0) | BGCTRL_16C | BGCTRL_NAME(MAP_TO_USE) |
               BGCTRL_H32 | BGCTRL_V32;
   PALRAM[0] = RGB(0, 0, 24);
   PALRAM[1] = RGB(31, 31, 28);
   while(LCD_Y != 226);
   LCDMODE = 0 | LCDMODE_BG0;

   while(1) ;
}

/*** end smiley.c ***/


/* Conclusions

Apparently, what would go in the BSS section in a "normal" binary
goes into DATA in a Devkit Advance ROM.

The multiboot crt0.s doesn't set up the malloc() arena in EWRAM
properly.  Has anybody been able to get Devkit Advance's malloc()
to work in multiboot?

*/

> RC5Stint wrote:
> >
> > The new GCC is a fully compliant C++ compiler.  String is a
> > standard class.  You are naming the char * parameter to
> > DrawString by the very same name, right down to the uppercase S.

> > If ever you port this to C++ and libstdc++, you'll go crazy
> > trying to diagnose this apparent non-error. :-)

Tony Wetmore replied:
>
> The string class defined by the C++ standard library is:
>
>     string  (actually, it's std::string)
>
> It does not use an upper-case 's'.  In fact, I can't think of
> any C++ standard types or keywords that use upper-case letters
> for anything. So there is no problem there.

Err, you're right.  I probably had a conniption and confused it with
Java's String, which I use just about every day at work.

- --
RC5Stint <rc5stint@...>
PGP Key ID: 0x3B4BEC6F

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (MingW32) - WinPT 0.5.1
Comment: For info see http://www.gnupg.org

iD8DBQE8WeCaifMcQztL7G8RAhvJAKC5BJTXXHpcACMANbUl0TS6iNGYTQCgrXwk
NPemKYS0lvu1oKtM6uScDUU=
=xqii
-----END PGP SIGNATURE-----

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

I doubt it ....
its a scripting lang, well it's designed to be embedded in a C app, you
might use it for AI scripts, but as the GBA has no file system they would be
hard coded, so you might as well just use C.

its gcc compilable, and from the docs it should be small enought to build
for gba
not too sure how exactly you woulds get you script in. I guess you might
want to experiment with serial comms to upload programs :)

I guess you've been to
http://www.lua.org
you can get the source from
http://www.tecgraf.puc-rio.br/lua/download.html
(which _should_ compile with the gba gcc)
and there's an IDE of sorts (designed for embedding Lua in win32 apps)
http://home.t-online.de/home/KZerbe/edelua.htm

I suspect that you are the only person who has thought about using Lua on a
GBA
Mike.

----- Original Message -----
From: "scn700" <scn700@...>
To: <gbadev@yahoogroups.com>
Sent: Thursday, January 31, 2002 7:22 PM
Subject: [gbadev] Lua


> hey all,
>
> i have heard about lua and great a programming language it is.
> has anyone used it for the gba and how?
>
> thanks
>

I've used it, and it's great!

There is a problem because it's written using setjmp and longjmp, so you
will have to get into the code a little and override this.

Javier

----- Original Message -----
From: "scn700" <scn700@...>
To: <gbadev@yahoogroups.com>
Sent: Jueves, 31 de Enero de 2002 04:22 p.m.
Subject: [gbadev] Lua


> hey all,
>
> i have heard about lua and great a programming language it is.
> has anyone used it for the gba and how?
>
> thanks

Use INCBIN statement in an assembly file.
That way you can pad it yourself.

Aelius.

>-----Original Message-----
>From: Jason Emery [mailto:felixd@...]
>Sent: Thursday, January 31, 2002 23:18
>To: gbadev@yahoogroups.com
>Subject: Re: [gbadev] How to add binary data files to projects?
>
>
>
>  Here is my problem: I would like to convert a (large) binary data file into
an object file so I can insert it into my
>project, thr problem is that I can't find a proper way to do it. Here is the
alternatives I found so far: (note that I'm
>using Visual C++ 6.0 and ARM Developer Suite 1.1)
>
>  1/ Convert the file to an array and let the compiler create the object.
>          Pros: easy to do, even you dont have a converter, you can write one
in less than 15 minutes.
>          Cons: the size of the output .c file increases exponentially compared
to the input binary file. At some point
>compiling the file can take up to 1/2 hour and eat more than 1g swap memory.
(the input data files are 8megabytes+ in size)
>
>  2/ Convert the file using bin2o by Darkfader.
>          Pros: easy to use and fast.
>          Cons: the output object file is byte array-based so it won't be
padded by the compiler, and you can have
>unaligned reads if you read more than one byte at a time. Also, the output file
cannot be used with MS's compiler.
>
>  3/ Convert the file using objcopy.
>          Pros: err, i can't find any, except that it outputs an (unusable)
object file.
>          Cons: data is moved to .data section (iwram) so i can't really use
it, plus it's unaligned as Darkfader's bin2o.
>Same remark regarding Visual Studio.
>
>  Please note that i'm using Visual with the embedded compiler, not GCC. (not
using gcc at all for compiling)
>
>  If someone have an idea on how to do that, i'll be grateful.
>
>What I plan on doing is creating raw files and importing via assembly .s files,
then assigning them global variables
>through extern statements in my C code.  This is done using the INCBIN command
as mentioned in the assembly program, then
>writing an extern to the symbol you use.
>
>An example of this assembly file is:
>
>.code 16
>.align 4
>.text
>.global VariableName
>.type VariableName,"object"
>VariableName:
>.incbin "filename.raw"
>
>And in C, you'd type:
>
>extern const char const VariableName[];
>
>Or some similar array type, depending on what you need, though I have yet to
test this thoroughly.
>
>Also, I've just written a program to convert a .c/.h file array to a .raw file
for this purpose, so I can use whatever
>data or program I want (many don't convert to .raw).  If anyone wants it, feel
free to ask.
>
>(My sprite file was 8 megs uncompiled, which was taking about a minute or two
to compile.)
>
>Jason Emery
>World Tree Games
>
>
>[Non-text portions of this message have been removed]
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>