If anyone is looking for a begginner site with demos with source or are
having trouble with compiling some of the pern project's examples, goto:
http://proger.netfirms.com/

GBA could be if someone wrote a TCP (or UDP) stack that could just be
#included to a project and then the project could possibly just call
TCPConnect or something similar... Considering GBA is a cartridge-based
system, someone good with hardware AND software could even possibly
build a network/modem plug into the cartridge for it to use... The
modem/network handler could also possibly be in a seperate chip so it
doesn't waste any of the GBA CPU...
Though what would be even nicer would be some kind of wireless internet
(such as in cell phones) builtin to a cartridge that also allows for an
external modem/network connection...

Thomas Nielsen [Liftoff] wrote:

> Xbox is a network enabled console - GBA is not. Its not like there's
> really any point in doing a tunnel for GBA, since it would require
> people have both Flashers and MVB-like cables, and special written
> software.
>
> Hardly anyone would bother writing that, and even fewer would care about
> playing.
>
> /Steve.
>
> -----Original Message-----
> From: brieder [mailto:brieder@...]
> Sent: 2. januar 2002 22:11
> To: gbadev@yahoogroups.com
> Subject: [gbadev] GBA Gateway/Tunnel?
>
> Has anyone thought about a GBA Gateway or Tunnel?  Like the two that
> exist for XBOX (http://www.xboxgw.com/ and Gamespy's).  There are
> GBA<->PC cables, Multiboot programs, etc.  Not saying that it would
> be easy, but it seems like all the pieces are there.  Any thoughts?
>
> Brett Rieder
>

It seems to me that emulators would be the perfect tool for detecting this
type of problem. Does anyone know of an emulator that can detect ROM writes?
I had a quick look at Mappy but couldn't see anything there that would
help - but I could be wrong.

-G

-----Original Message-----
From: Francis Lillie [mailto:francis_lillie@...]
Sent: Saturday, January 05, 2002 3:14 AM
To: gbadev@yahoogroups.com
Subject: RE: [gbadev] Cartridge crash problem...


Well, I had exactly the same problem.  In my case it was the ONLY place in
my project that a sprite was being displayed a co-ordinate from a ROM table,
not a generated position.  The sprite function tried to subtract handles
from the sprite positions (ROM) and died.

So, I reckon it's an inadvertant write to ROM that's the problem.  The
proper N cart's seem to pick them up, but the Visoly ones don't, and since
it takes under half the time to burn a Visoly cart, I never used an N one so
was never aware of the problem.

You're quite lucky that it crashes really, as I was, as apparently an
attempt to write to ROM results in random operation, and I beleive one of my
colleagues spent a long time trying to sort the same problem, as their crash
could take place after 5 seconds, 5 minutes or 5 hours, and the only reason
I know about this problem is because he told me :)

Hope this waffle helps.

FGL

Xbox is a network enabled console - GBA is not. Its not like there's
really any point in doing a tunnel for GBA, since it would require
people have both Flashers and MVB-like cables, and special written
software.

Hardly anyone would bother writing that, and even fewer would care about
playing.

/Steve.

-----Original Message-----
From: brieder [mailto:brieder@...]
Sent: 2. januar 2002 22:11
To: gbadev@yahoogroups.com
Subject: [gbadev] GBA Gateway/Tunnel?

Has anyone thought about a GBA Gateway or Tunnel?  Like the two that
exist for XBOX (http://www.xboxgw.com/ and Gamespy's).  There are
GBA<->PC cables, Multiboot programs, etc.  Not saying that it would
be easy, but it seems like all the pieces are there.  Any thoughts?

Brett Rieder




list rules: http://www.gbadev.org/rules.txt
unsubscribe: gbadev-unsubscribe@yahoogroups.com



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

Maybe you could check your prefetch settings.

On official cartridges, you have to set them to 3-1-1.

Codac/Apex
http://hferradj.nerim.net




-----Message d'origine-----
De : Gimbel Baxter [mailto:gimbel@...]
Envoye : samedi 5 janvier 2002 01:06
A : gbadev@yahoogroups.com
Objet : [gbadev] Cartridge crash problem...


Any help on this problem would be greatly appreciated.

I have a gba binary file (of my own making), compiled with GCC. Burned onto
a real cart using Visoly's Advance Flash Linker. I'm using a tall 64Mb Flash
card and the code is under 8Mb.

Everything runs fine. No problems on either the real thing or emulated.

The problem is when the aforementioned binary file is burned onto an
official Nintendo development cart (the stand alone unit - not the one with
cables attached). When the Gameboy is turned on, it gets passed the
registration info (i.e. the Gameboy logo fades out) but as soon as it hits
my code the unit locks up.

Any ideas?


-G

Well, I had exactly the same problem.  In my case it was the ONLY place in
my project that a sprite was being displayed a co-ordinate from a ROM table,
not a generated position.  The sprite function tried to subtract handles
from the sprite positions (ROM) and died.

So, I reckon it's an inadvertant write to ROM that's the problem.  The
proper N cart's seem to pick them up, but the Visoly ones don't, and since
it takes under half the time to burn a Visoly cart, I never used an N one so
was never aware of the problem.

You're quite lucky that it crashes really, as I was, as apparently an
attempt to write to ROM results in random operation, and I beleive one of my
colleagues spent a long time trying to sort the same problem, as their crash
could take place after 5 seconds, 5 minutes or 5 hours, and the only reason
I know about this problem is because he told me :)

Hope this waffle helps.

FGL

--- In gbadev@y..., "bobscar.geo" <conraderj@a...> wrote:

> It was a while ago, so I am not exactly sure what happened.

> I was using gcc 3.0.

> I was trying to create the arm-thumb-elf compiler. (I used

> ./configure --target=arm-thumb-elf.) The configure part worked fine.

> I then tried to compile and it went a long way and then ends with the

> following errors.


[snip]

> -----------

> I pretty much gave up after that. I have not tried again. I was using the
instructions from

> http://www.devrs.com/gba/files/dwcygwin.txt. Is there a place with

> instructions that work better?


(I'm using OpenBSD, but the differences should be minimal)

I started with http://www.io.com/~fenix/devkitadv/
I used the patches etc from agb-source-r4.zip, and the Makefile
from agb-linux-source-r1.zip

The Makefile needs a few small changes
* use $(MAKE) instead of make, and call with gmake
* use "patch -l -p0 < foo"
* bump the version numbers to current

I've got gcc-3.0.3 to build without c++, but libstdc++ needs a
few more tweaks (missing typedefs). I hope to finish those this
weekend.

gbatag wrote:
> also no longer needed.  So simply adding "int __gba_multiboot;"
> (*without* the "const") to the main C++ file did the trick.

  I have removed the "const" from the suggestions in crt0.S and
lnkscript in the crtls.zip on my site. I added that to save RAM
space but obviously it causes problems it appears. Thanks for
catching that, Tiaan.

  Also, I apologize for some of my previous posts where I have
pointed out that some of the questions that people have asked
are in the GBA Dev FAQs on devrs.com/gba. In particular, in a
few cases I failed to mention that I recently (same day?) added
that question to the FAQs. Failing to mention this, I now realize,
might have given the impression that someone failed to read
those FAQs first, which wouldn't necessarily be a correct impression.
Sorry about that. I'll try to be more careful in the future.
No one has yet complained but they probably would have been well
justified in doing so.

  xiexie, (Thank you in Mandarin Chinese, IIRC)

  Jeff

Any help on this problem would be greatly appreciated.

I have a gba binary file (of my own making), compiled with GCC. Burned onto
a real cart using Visoly's Advance Flash Linker. I'm using a tall 64Mb Flash
card and the code is under 8Mb.

Everything runs fine. No problems on either the real thing or emulated.

The problem is when the aforementioned binary file is burned onto an
official Nintendo development cart (the stand alone unit - not the one with
cables attached). When the Gameboy is turned on, it gets passed the
registration info (i.e. the Gameboy logo fades out) but as soon as it hits
my code the unit locks up.

Any ideas?


-G

You may want to try enabling the timer interrupt, and put your
countdown-til-buffer-swap in the timer interrupt handler, that way
you don't have to worry about synchronization.  If you can eliminate
the need for timer 0, you can cascade 1 into 0, put the countdown in
timer 0, then generate a single interrupt when the buffer swap is
needed.  If you're still getting the click, you may need to issue the
swap earlier (maybe the FIFO is starved)

John Marco Panettiere

--- In gbadev@y..., "Tristan Rybak" <tristan.rybak@w...> wrote:
> I think, that's not the problem. I isolated my code so there is no
other DMA transfer then that feeding SOUND FIFO's.
> And I don't use DMA interrupt when sound completes (I use VBLANK).
> I think the problem is in synchronizing DMA restart with VBLANK.
But I can not find working values of frequency/buffer size.
> When I use emulator and read DMA SOURCE ADDRESS at VBLANK IRQ (it's
possible in emulator) the address is pointing at the first byte after
my buffer and sometimes (lets say every 4th sound click:-) 16 bytes
after. I guess DMA is feeding sound fifo 16 bytes a time.
> But I know emulator is not enough reliable for such measurements.
> I have no idea what to do, If someone share with me working buffer
switching routine (at vblank) that would be great.
> Thanks very much
> Tristan
>   ----- Original Message -----
>   From: rogermilne100
>   To: gbadev@y...
>   Sent: Friday, January 04, 2002 6:17 AM
>   Subject: [gbadev] Re: sound loop problem, please help!!!
>
>
>   If you are performing DMA's *anywhere* in your code, while the
sound
>   is playing, you risk pre-empting the CPU's interrupt handler from
>   being able to feed more sound when the existing sample
completes.
>   That situation caused random, intermittant clicking in my code.
>   Basically, you really have to make sure that when the sound DMA
>   completes its' last transfer, and generates an interrupt so that
it
>   can be given more sample-data, you really need to service it
ASAP.
>   DMA's take higher precidence than CPU, and if active when the
>   interrupt is triggered, can cause a delay before the interrupt is
>   serviced, and thus, a click is heard once in a while.  There may
be
>   more reasons for these clicks, but that's the only problem I ran
into
>   which caused them.  I hope that helps lead to a solution...
>
>       Roger

I had similar problems with sound, but after reading
http://belogic.com/gba/, I came up with a solution. Instead of trying
to mix sounds once per frame, just use the timer interrupt and mix
one sample at a time. Actually, it's 4 samples at a time since the
FIFO buffer is 4 bytes, and that also causes problems because the
timer interrupt comes once per sample, so you have to use one timer
for frequency and another for the interrupt. A sample rate of 16384
is the easiest to deal with, cause you can just set the timer
multiplier to 1024, and the timer data to 0xFFFF. That also means you
can just use 0xFFFF - 3 for the IRQ timer.

Another solution would be to use a sampling rate that's divisible by
60, so you don't end up with any extra/missed samples. That was you
can use DMA to transfer data to the FIFO, which is faster than the
timer IRQ method. Again 16384 is good, since it's almost perfectly
divisible by 60, but if you want higher, 21000 is exactly 350 samples
per frame.

--- In gbadev@y..., "Tristan Rybak" <tristan.rybak@w...> wrote:
> I think, that's not the problem. I isolated my code so there is no
other DMA transfer then that feeding SOUND FIFO's.


[cropped by mod]

>There's a section providing some details on the CPPTest example, written by
>Jaap Suter if I'm not mistaken.

Before I start getting credit for stuff I didn't do I'd like to say it
wasn't me who wrote this example. For now I'm sticking to C only. I don't
know who did wrote the example, but he'll deserve all the credit.

Goodluck with your problem btw...

Grz,

Jape

January 25th 2002, very good things will come: http://jaap.flipcode.com

_________________________________________________________________
MSN Foto's is de eenvoudigste manier om je foto's te delen en af te drukken:
http://photos.msn.nl/Support/WorldWide.aspx

It was a while ago, so I am not exactly sure what happened.
I was using gcc 3.0.
I was trying to create the arm-thumb-elf compiler. (I used
./configure --target=arm-thumb-elf.) The configure part worked fine.
I then tried to compile and it went a long way and then ends with the
following errors.

/volumes/data/applications/dev/thumb/gcc-3.0/gcc/f/global.c:65:
illegal message expression, found `]'
/volumes/data/applications/dev/thumb/gcc-3.0/gcc/f/global.c:72:
illegal external declaration, missing `;' after `?any?'
cpp-precomp: warning: errors during smart preprocessing, retrying in
basic mode
/volumes/data/applications/dev/thumb/gcc-3.0/gcc/f/global.c:65: parse
error before `,'
/volumes/data/applications/dev/thumb/gcc-3.0/gcc/f/global.c:66: parse
error before `,'
/volumes/data/applications/dev/thumb/gcc-3.0/gcc/f/global.c:67: parse
error before `,'
/volumes/data/applications/dev/thumb/gcc-3.0/gcc/f/global.c:68: parse
error before `,'
/volumes/data/applications/dev/thumb/gcc-3.0/gcc/f/global.c:69: parse
error before `,'
/volumes/data/applications/dev/thumb/gcc-3.0/gcc/f/global.c:70: parse
error before `,'
/volumes/data/applications/dev/thumb/gcc-3.0/gcc/f/global.c:71: parse
error before `,'
/volumes/data/applications/dev/thumb/gcc-3.0/gcc/f/global.c:73: parse
error before `}'
make[1]: *** [f/global.o] Error 1
make: *** [install-gcc] Error 2

-----------
I pretty much gave up after that. I have not tried again. I was using the
instructions from
http://www.devrs.com/gba/files/dwcygwin.txt. Is there a place with
instructions that work better?

Thanks,
John

--- In gbadev@y..., "Toby Hutton" <vjfaq5yxe12s001@s...> wrote:
> bobscar.geo conraderj@a... XXXXXXXXXXXXXXXXXXXX writes:
>  > I would be interested in knowing how you compiled the devkit on
BSD.
>  >
>  > I was trying to get it to work on Mac OS X - a little BSD
heritage
>  > somewhere in there. I had all kinds of problems getting the
compiler
>  > set up to do the arm stuff. I finally gave up.
> All I did was use the patches from devkitadv (the most valuable
part)
> and applied them and did the standard configure/make/make install.
> What problems are you having specifically?  What version of gcc is
> used as the OS X native compiler?
> --
> Toby.

I think, that's not the problem. I isolated my code so there is no other DMA
transfer then that feeding SOUND FIFO's.
And I don't use DMA interrupt when sound completes (I use VBLANK).
I think the problem is in synchronizing DMA restart with VBLANK. But I can not
find working values of frequency/buffer size.
When I use emulator and read DMA SOURCE ADDRESS at VBLANK IRQ (it's possible in
emulator) the address is pointing at the first byte after my buffer and
sometimes (lets say every 4th sound click:-) 16 bytes after. I guess DMA is
feeding sound fifo 16 bytes a time.
But I know emulator is not enough reliable for such measurements.
I have no idea what to do, If someone share with me working buffer switching
routine (at vblank) that would be great.
Thanks very much
Tristan
   ----- Original Message -----
   From: rogermilne100
   To: gbadev@yahoogroups.com
   Sent: Friday, January 04, 2002 6:17 AM
   Subject: [gbadev] Re: sound loop problem, please help!!!


   If you are performing DMA's *anywhere* in your code, while the sound
   is playing, you risk pre-empting the CPU's interrupt handler from
   being able to feed more sound when the existing sample completes.
   That situation caused random, intermittant clicking in my code.
   Basically, you really have to make sure that when the sound DMA
   completes its' last transfer, and generates an interrupt so that it
   can be given more sample-data, you really need to service it ASAP.
   DMA's take higher precidence than CPU, and if active when the
   interrupt is triggered, can cause a delay before the interrupt is
   serviced, and thus, a click is heard once in a while.  There may be
   more reasons for these clicks, but that's the only problem I ran into
   which caused them.  I hope that helps lead to a solution...

       Roger




         Yahoo! Groups Sponsor
               ADVERTISEMENT




   list rules: http://www.gbadev.org/rules.txt
   unsubscribe: gbadev-unsubscribe@yahoogroups.com



   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



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

If you are performing DMA's *anywhere* in your code, while the sound
is playing, you risk pre-empting the CPU's interrupt handler from
being able to feed more sound when the existing sample completes.
That situation caused random, intermittant clicking in my code.
Basically, you really have to make sure that when the sound DMA
completes its' last transfer, and generates an interrupt so that it
can be given more sample-data, you really need to service it ASAP.
DMA's take higher precidence than CPU, and if active when the
interrupt is triggered, can cause a delay before the interrupt is
serviced, and thus, a click is heard once in a while.  There may be
more reasons for these clicks, but that's the only problem I ran into
which caused them.  I hope that helps lead to a solution...

     Roger

Jeff F. suggested that I should use the linker's -Map command-line
option to generate a map file.  From that I was able to figure out
that the code ended up at address 0x08000000 instead of 0x02000000
(as it should for multiboot).  When I initially added the variable
declaration I did it as follows: "volatile const int __gba_multiboot
= 1;" (I had to add the "= 1" for it to compile without errors in C++
mode).  Even when I did this the variable still wouldn't show up in
the map file.  Eventually I removed the "const" from the declaration
and suddenly the variable appeared in the map file and the code
appeared at address 0x02000000.  It seems to me that the C++ compiler
treats a const variable similar to a #define, and doesn't actually
assign a memory address to it (some sort of optimization).  When I
removed the "const" from the declaration the "= 1" assignment was
also no longer needed.  So simply adding "int __gba_multiboot;"
(*without* the "const") to the main C++ file did the trick.  Thanks a
lot, Jeff, for pointing me in the right direction.


--- In gbadev@y..., "gbatag" <Tiaan_Geldenhuys@h...> wrote:
> Hi,
>
> Over the past few days I've been trying to get some C++ code to
> compile and were able to do so.  The code runs fine on the Mappy
> emulator but when transferring the multiboot image to my GBA using
> the MBV2 cable I simply get a blank screen once the transfer
> completes.  What could be the problem?
>
> After looking through some group posts and browsing the web, I
> eventually found some useful information about compiling C++ code
for
> the GBA in the "Newbie's Guide to GameBoy Advance Development", by
> VerticalE.  There's a section providing some details on the CPPTest
> example, written by Jaap Suter if I'm not mistaken, which I used to
> figure out how to get my C++ code to compile.  Following that
> example's documentation to the letter, which also includes the
source
> code, I can produce a binary that have this behavior: it runs on
the
> emulator but not on the hardware.  The example simply sets up
> graphics Mode 3, paints the screen blue and then has an endless
> loop.  It uses Jeff Frohwein's startup code (based on crt0.S v1.25)
> with the ".equ __MultiBootInclude, 1" and ".equ __CPPSupport, 1"
> lines defined.  It doesn't define the __gba_multiboot variable in
> main.cpp, but even doing so doesn't make any difference.
>
> When compiling my own application as a pure C application it works
> just fine on both hardware and emulator – it uses graphics Mode 0.
> But when calling this code from a basic C++ class and then
compiling
> it, it just won't work on real hardware.  In my application I've
used
> Jeff's latest crt0.S & Linkscript code and am using the crtbegin.o
&
> crtend.o files that come with the latest version of DevKitAdvance.
>
> Could it be a memory alignment issue, or maybe a name mangling
issue
> with the __gba_multiboot variable?  What other differences could
> there be?  Any help would be appreciated.
>
> Thanks,
> Tiaan.

I am writing mixer, using stereo DMA1/2 transfer, drived by timer0.
I am using double buffering that means my buffer have samples for two
VBLANK periods (DMA restart is every second vblank). Mixer frequency
is 22075 hz.
so timer0 counter value is 0xffff-(2^24 / 22075) ~= 0xfd08
and buffer size = 22075/60 ~= 368

my routine is unstable, that means it generates click not every
buffer restart (30 a second) but at lower frequency.

I have written two routines, one to init mixer (dma, sound output)
and second to restart DMA.

I tried everything (except the thing that would help :-)
(enlarging buffer, slightly changing timer frequency, resetting timer
every second vblank with DMA reset, starting timer in init routine
synchronized to 160 vline).
Maybe I am using not valid frequency.
I tested it on software VisualBoyAdvance and hardware with flash
linker.
I cannot get rid of strange clicks and sounds in my samples. I fight
with that for few days and going out of my nerves. Here is my code,
please please help!!!
(Maybe someone will support me with such working routine.)

... mixer.s

SAMPLES_PER_VBLANK = 368
SOUND_BUFFERS  = 2

SOUND_CONTROL_LOW  = 0x0080
SOUND_CONTROL_HIGH  = 0x0082
SOUND_CONTROL 	 = 0x0084
SOUND_FIFO_A 	 = 0x00A0
SOUND_FIFO_B 	 = 0x00A4

SOUND_FIFO_A_RATIO_HALF  = 0x0000
SOUND_FIFO_A_RATIO_FULL  = 0x0004
SOUND_FIFO_B_RATIO_HALF  = 0x0000
SOUND_FIFO_B_RATIO_FULL  = 0x0008
SOUND_FIFO_A_OUTPUT_R  = 0x0100
SOUND_FIFO_A_OUTPUT_L  = 0x0200
SOUND_FIFO_A_TIMER_0  = 0x0000
SOUND_FIFO_A_TIMER_1  = 0x0400
SOUND_FIFO_A_RESET  = 0x0800
SOUND_FIFO_B_OUTPUT_R  = 0x1000
SOUND_FIFO_B_OUTPUT_L  = 0x2000
SOUND_FIFO_B_TIMER_0  = 0x0000
SOUND_FIFO_B_TIMER_1  = 0x4000
SOUND_FIFO_B_RESET  = 0x8000

SOUND_CIRCUIT_ENABLE  = 0x0080

DMA1_SOURCE_ADDRESS  = 0x00BC
DMA1_DESTINATION_ADDRESS = 0x00C0
DMA1_WORD_COUNT 	 = 0x00C4
DMA1_CONTROL 	 = 0x00C6

DMA2_SOURCE_ADDRESS  = 0x00C8
DMA2_DESTINATION_ADDRESS = 0x00CC
DMA2_WORD_COUNT 	 = 0x00D0
DMA2_CONTROL 	 = 0x00D2

DMA_ENABLE_FLAG 	 = 0x8000
DMA_START_ON_SOUND_FIFO  = 0x3000
DMA_TRANSFER_32BIT  = 0x0400
DMA_REPEAT 	 = 0x0200
DMA_SOURCE_INCREMENT  = 0x0000
DMA_DESTINATION_FIXED  = 0x0040

TIMER0_SETTING 		 = 0x00
TIMER0_CONTROL 		 = 0x02

TIMER_START_TIMER 	 = 0x0080
TIMER_PRESCALE_1 	 = 0x0000

			 .section .iwram
			 .balign 4
left_channel:  .space SOUND_BUFFERS*SAMPLES_PER_VBLANK
right_channel:  .space SOUND_BUFFERS*SAMPLES_PER_VBLANK
first_vbl:  .word 0
second_vbl:  .word 0
timer0_mix_freq: .word 0xfd08


left_channel_address: .word left_channel
right_channel_address: .word right_channel
first_vbl_address: .word first_vbl
second_vbl_address: .word second_vbl

mixer_init:
			 stmfd sp!, {r0, r1, lr}

			 mov r0, #0
			 ldr r1, first_vbl_address
			 str r0, [r1]
			 ldr r1, second_vbl_address
			 str r0, [r1]

			 mov r1, #0x04000000
		 @ set DMA source
			 ldr r2, left_channel_address
			 str r2, [r1, #DMA1_SOURCE_ADDRESS]
			 ldr r2, right_channel_address
			 str r2, [r1, #DMA2_SOURCE_ADDRESS]

		 @ set DMA dest
			 mov r0, r1
			 add r0, r0, #SOUND_FIFO_A
			 str r0, [r1, #DMA1_DESTINATION_ADDRESS]
			 mov r0, r1
			 add r0, r0, #SOUND_FIFO_B
			 str r0, [r1, #DMA2_DESTINATION_ADDRESS]

		 @enable DMA
			 mov r0, #DMA_ENABLE_FLAG |
DMA_START_ON_SOUND_FIFO | DMA_TRANSFER_32BIT | DMA_REPEAT
			 orr r0, r0, #DMA_SOURCE_INCREMENT |
DMA_DESTINATION_FIXED
			 strh r0,  [r1, #DMA1_CONTROL]
			 strh r0,  [r1, #DMA2_CONTROL]

		 @ setup Direct Sound Volume & Output
			 mov r0, #SOUND_FIFO_A_RESET |
SOUND_FIFO_B_RESET | SOUND_FIFO_A_TIMER_0 | SOUND_FIFO_B_TIMER_0
			 orr r0, r0, #SOUND_FIFO_A_RATIO_FULL |
SOUND_FIFO_B_RATIO_FULL
			 orr r0, r0, #SOUND_FIFO_A_OUTPUT_L |
SOUND_FIFO_B_OUTPUT_R
			 strh r0, [r1, #SOUND_CONTROL_HIGH]

			 mov r0, #SOUND_CIRCUIT_ENABLE
			 strh r0, [r1, #SOUND_CONTROL]


			 ldmfd sp!, {r0, r1, lr}
			 mov pc, lr

VBLANK:
			 stmfd sp!, {r0-r2, lr}
			 bl mixer_dma
			 mov r1, #0x04000000
			 orr r1, r1, #0x200
			 mov r0, #1
			 str r0, [r1, #2]
			 ldmfd sp!, {r0-r2, lr}
			 mov pc, lr


mixer_dma:
			 stmfd sp!, {r0-r2}

		 @ flip buffers (r0 = current buffer)
			 ldr r1, second_vbl_address
			 ldr r0, [r1]
			 add r0, r0, #1
			 cmp r0, #3
			 blt mixer_dma_not_reset

		 @ reset DMA
			 mov r1, #0x04000000
			 mov r0, #0
			 strh r0,  [r1, #DMA1_CONTROL]
			 strh r0,  [r1, #DMA2_CONTROL]

		 @ set DMA source
			 ldr r2, left_channel_address
			 str r2, [r1, #DMA1_SOURCE_ADDRESS]
			 ldr r2, right_channel_address
			 str r2, [r1, #DMA2_SOURCE_ADDRESS]

		 @enable DMA
			 mov r0, #DMA_ENABLE_FLAG |
DMA_START_ON_SOUND_FIFO | DMA_TRANSFER_32BIT | DMA_REPEAT
			 orr r0, r0, #DMA_SOURCE_INCREMENT |
DMA_DESTINATION_FIXED
			 strh r0,  [r1, #DMA1_CONTROL]
			 strh r0,  [r1, #DMA2_CONTROL]

			 mov r0, #0
mixer_dma_not_reset:
			 ldr r1, second_vbl_address
			 str r0, [r1]

			 ldr r1, first_vbl_address
			 ldr r0, [r1]
			 cmp r0, #0
			 bne mixer_dma_second_vbl
			 mov r0, #1
			 str r0, [r1]

		 @ setup Timer0 frequency & enable it
			 mov r1, #0x04000000
			 add r1, r1, #0x0100
			 ldr r0, timer0_mix_freq
			 strh r0, [r1, #TIMER0_SETTING]
			 mov r0, #TIMER_START_TIMER | TIMER_PRESCALE_1
			 strh r0, [r1, #TIMER0_CONTROL]
mixer_dma_second_vbl:
			 ldmfd sp!, {r0-r2}
			 mov pc, lr

Thanks in advance
Tristan Rybak
rybak@...

I had problems doing multiboot with gcc, its ugly but it worked, see the
dhrygccmb.zip file at http://www.dwelch.com/gba/dhry.htm for the makefile

Here is the crt0.s that I used...

     .TEXT

     .GLOBAL     _start
_start:
         .ALIGN
         .CODE 32
         b       start_vector

     .word 0,0,0,0,0,0,0,0
     .word 0,0,0,0,0,0,0,0
     .word 0,0,0,0,0,0,0,0
     .word 0,0,0,0,0,0,0,0
     .word 0,0,0,0,0,0,0,0
     .word 0,0,0,0,0,0,0,0
     .word 0,0,0,0,0,0,0,0
     .word 0,0,0,0,0,0,0,0
     .word 0,0,0,0,0,0,0,0
     .word 0,0,0,0,0,0,0,0
     .word 0,0,0,0,0,0,0,0

start_vector:

     b main

     .END



----- Original Message -----
From: gbatag
Sent: 1/3/2002 10:36:13 AM
To: gbadev@yahoogroups.com
Subject: [gbadev] C++ example working on Mappy, but not hardware (using MBV2)

> Hi,
>
> Over the past few days I've been trying to get some C++ code to
> compile and were able to do so.  The code runs fine on the Mappy
> emulator but when transferring the multiboot image to my GBA using
> the MBV2 cable I simply get a blank screen once the transfer
> completes.  What could be the problem?
>
> After looking through some group posts and browsing the web, I
> eventually found some useful information about compiling C++ code for
> the GBA in the "Newbie's Guide to GameBoy Advance Development", by
> VerticalE.  There's a section providing some details on the CPPTest
> example, written by Jaap Suter if I'm not mistaken, which I used to
> figure out how to get my C++ code to compile.  Following that
> example's documentation to the letter, which also includes the source
> code, I can produce a binary that have this behavior: it runs on the
> emulator but not on the hardware.  The example simply sets up
> graphics Mode 3, paints the screen blue and then has an endless
> loop.  It uses Jeff Frohwein's startup code (based on crt0.S v1.25)
> with the ".equ __MultiBootInclude, 1" and ".equ __CPPSupport, 1"
> lines defined.  It doesn't define the __gba_multiboot variable in
> main.cpp, but even doing so doesn't make any difference.
>
> When compiling my own application as a pure C application it works
> just fine on both hardware and emulator ? it uses graphics Mode 0.
> But when calling this code from a basic C++ class and then compiling
> it, it just won't work on real hardware.  In my application I've used
> Jeff's latest crt0.S & Linkscript code and am using the crtbegin.o &
> crtend.o files that come with the latest version of DevKitAdvance.
>
> Could it be a memory alignment issue, or maybe a name mangling issue
> with the __gba_multiboot variable?  What other differences could
> there be?  Any help would be appreciated.
>
> Thanks,
> Tiaan.
>
>
>
>
>
> list rules: http://www.gbadev.org/rules.txt
> unsubscribe: gbadev-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Hi,

Over the past few days I've been trying to get some C++ code to
compile and were able to do so.  The code runs fine on the Mappy
emulator but when transferring the multiboot image to my GBA using
the MBV2 cable I simply get a blank screen once the transfer
completes.  What could be the problem?

After looking through some group posts and browsing the web, I
eventually found some useful information about compiling C++ code for
the GBA in the "Newbie's Guide to GameBoy Advance Development", by
VerticalE.  There's a section providing some details on the CPPTest
example, written by Jaap Suter if I'm not mistaken, which I used to
figure out how to get my C++ code to compile.  Following that
example's documentation to the letter, which also includes the source
code, I can produce a binary that have this behavior: it runs on the
emulator but not on the hardware.  The example simply sets up
graphics Mode 3, paints the screen blue and then has an endless
loop.  It uses Jeff Frohwein's startup code (based on crt0.S v1.25)
with the ".equ __MultiBootInclude, 1" and ".equ __CPPSupport, 1"
lines defined.  It doesn't define the __gba_multiboot variable in
main.cpp, but even doing so doesn't make any difference.

When compiling my own application as a pure C application it works
just fine on both hardware and emulator – it uses graphics Mode 0.
But when calling this code from a basic C++ class and then compiling
it, it just won't work on real hardware.  In my application I've used
Jeff's latest crt0.S & Linkscript code and am using the crtbegin.o &
crtend.o files that come with the latest version of DevKitAdvance.

Could it be a memory alignment issue, or maybe a name mangling issue
with the __gba_multiboot variable?  What other differences could
there be?  Any help would be appreciated.

Thanks,
Tiaan.

Hello kinetic_creationz,

Wednesday, January 02, 2002, 8:48:56 PM, you wrote:

> I'm trying to load 2 different 16 colour palettes for 2 different
> sprites in mode 0. I'm using 16 colour mode for the sprites but when
> I DMA the sprites and the palettes into VRAM one of the sprites isn't
> right. I load one palette like this:

> DmaArrayCopy(3, duckt_pal, (0 * 32) + OBJ_PLTT, 32);

> and the other simply like this:

> DmaArrayCopy(3, square_pal, (1 * 32) + OBJ_PLTT, 32);

> But the sprites both seem to use the first palette. How do you assign
> palette 1 to a sprite? Thanks in advance.
You do activate your palettes, but do you also set their indices in OAM
entries? The highest 4 bits of "attribute 2" [bytes 5/6] should
contain the index (0-15) of your palette (please also make sure that
your sprites use 16x16 mode -- this is bit 10 of "attribute 0", it
should be cleared). So, what you have to do is set palette index for
your second sprite to 1 and it should work ok.

--
cheers,
-Maciej

--- In gbadev@y..., Davide Inglima <limacat@l...> wrote:
> On Thursday 20 December 2001 16:08, you wrote:
>
> > PPS I use gcc to do my linking not ld.
>
> If I'm not mistaken it should be the same.
> Gcc is a frontend to both the C and C++ compiler, the assembler and
the
> linker.

Yes, but if you call it instead of ld then it automatically includes
the crt0.o file from inside your include directory structure
depending on what flags you use (ie thumb and/or interworking).. or
at least thats what the version of devkitadv that I have does. It's
slightly annoying becuase the crt0.S file wasn't included in my
distribution, so i have no idea what's inside it ;)

Basically what I'm saying is that if they can't get it to work, then
try using gcc. If that works then most of your problems are over
until you want to do some specialised work like altering your
linkscript or ctr0.

O

> But the sprites both seem to use the first palette. How do you
assign
> palette 1 to a sprite? Thanks in advance.

From the cowbite spec
(http://www.gbadev.org/files/CowBiteSpec_dec29.zip)
You set the palette number by setting the top 4 bits of attribute 2.
Eg
*attribute2=(palletenum<<12)+(priority<<10)+sprite


Bytes 5 and 6 (Attribute 2)

F E D C B A 9 8 7 6 5 4 3 2 1 0
L L L L P P T T T T T T T T T T

L = Palette number. If you use 16 color palettes, this tells you
which pallette number to use.
P = Priority. This controls the priority of the sprite. Note thate
sprites take precedence over backgrounds of the same priority.
T = Tile number. This value indexes selects the bitmap of the tile to
be displayed by indexing into the tile data area.

If by "rom call" you mean a bios call, then yes its legal as long as you don't
do anything stupid and distribute any copyright material such as the bios with
your work.

In message <F186eOLn9WdjpdsKkSX0000c569@...> gbadev@yahoogroups.com
writes:
> Hello, its legal use rom call to gba in my project?
>
> thanks

Hello, its legal use rom call to gba in my project?

thanks


Pablo Testa
email: drakssen@...




_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

Maciej Sinilo <yrp@...> wrote:

> >> Has anyone tried using the C++ Standard Template Library with the
> >> DevKitAdv or other gcc-based setup?  If so, did you have any luck
> >> getting it to work?
> >
> > The problem must be with DevKitAdv:  we use the STL (and Boost)
> > extensively in our project with the gcc compiler from Nintendo (for
> > registered developers) without any problems.
>
> Aren't you afraid of code bloat? Using STL tends to result in very
> big code being generated (of course it depends which parts do you
> use, I don't expect std::min to add kilobytes, but you wrote you use
> it extensively, so I guess you talk about containers/algorithms?).

Code "bloat" could be a problem if you are very tight on ROM space,
but your images and other data will have a much bigger impact than
code.  The reason I put bloat in quotes is that it sounds like your
code will get huge if you just put "#include <list>" in your file,
but compilers _need_ to only generate code for elements you use.
That means that even if you use std::list, but don't use the merge()
function of that template, code will not be generated for it.  Also
consider that if you tend to need to keep containers of several
different types of objects around (don't we all?), you only have a
few options.  If code bloat is your primary concern, you could write
your own list implementation that stores void pointers that you cast
to/from (run & compile time efficient but not type safe).  You could
make your own list implementation for each object type that you will
be using (still efficient and type safe, but redundant, error prone,
and bigger binary).  Or you could let templates do the dirty work
for you (only downside is a bigger binary).

There are other factors to keep in mind as well: the STL is already
written which saves you much time and effort, it's relatively bug free
which also save you time and effort, it's highly optimized (you would
probably never write code that efficient yourself), and it has complex
containers and algorithms (do you really want to write your own red-
black tree or inner product function?), etc.

So before you dismiss templates because of bloat, you should weigh
whether or not they will be worthwhile in your particular situation,
considering the measurable and estimated, schedule, run, and compile
time impacts of templates versus other solutions.


Toby Hutton <vjfaq5yxe12s001@...> wrote:
>
> Gcc's STL sucks arse.  If you've used STL elsewhere you'll find the
> GNU version very limited.
>
> In my professional experience we've always avoided using STL, but
> that's mainly because it's absolutely not portable (which isn't
> really a problem here.)  Well, STL itself is portable but each of
> the implementations aren't.

GCC's STL implementation might be bad, I wouldn't know:  when we found
out how bad the Visual C++ implementation was a few years back, we
switched to STLport and use it in all of our projects.  It is a free,
highly portable, quality implementation.  You really should investigate
it (www.stlport.org).  You will probably have to set a few configuration
options, especially for AGB development (see example below).

Good luck,
Ben


#define _STLP_NO_OWN_IOSTREAMS 1 // use compiler's default IO streams
#define _STLP_NO_EXTENSIONS 1 // use standard STL without enhancements
#define _STLP_USE_NEWALLOC 1 // use compiler's "new" for allocations
#define _STLP_NO_EXCEPTIONS 1 // disable exceptions
#define _STLP_NO_DEBUG_EXCEPTIONS 1 // thrown from __stl_debug_terminate

#if defined(DEBUG) || defined(_DEBUG)
	 #define _STLP_DEBUG 1
	 #define _STLP_ASSERTIONS 1
	 #define _STLP_DEBUG_UNINITIALIZED 1
	 #define _STLP_SHRED_BYTE ((unsigned char)'\xA3')
#endif

#ifdef AGB
	 // turn off IO streams altogether
	 #ifdef _STLP_NO_OWN_IOSTREAMS
		 #undef _STLP_NO_OWN_IOSTREAMS
	 #endif
	 #define _STLP_NO_IOSTREAMS 1

	 #define _STLP_NO_WCHAR_T 1 // no wide character support
	 #define _STLP_NO_THREADS 1 // no threading support

	 #if defined(DEBUG) || defined(_DEBUG)
		 #define _STLP_DEBUG_MESSAGE 1
		 #define _STLP_DEBUG_TERMINATE 1
	 #endif
#endif


--
Benbuck Nason
"Of course we gotta pay rent, so money connects, but I'd rather be broke
                and have a whole lot of respect." - O.C.

Has anyone thought about a GBA Gateway or Tunnel?  Like the two that
exist for XBOX (http://www.xboxgw.com/ and Gamespy's).  There are
GBA<->PC cables, Multiboot programs, etc.  Not saying that it would
be easy, but it seems like all the pieces are there.  Any thoughts?

Brett Rieder

Sorry, this post I'm replying to is old ... and long ...

John Q. Pretentious wrote:

=== on the topic of the bit depth input into the GBA FIFO ===

> > In 9-bit mode the extra bit is just
> > "invented" by the system so it's still just 8-bit sound.
>
> The nine bits of data *are* being interpreted by the system.  Otherwise,
> that ninth bit I put in the waveform should have wreaked havoc, and it
> didn't.  Moreover, 8-bit data filled in in the 9-bit mode sounds
completely
> wrong.

Are you saying that the data is sent into the FIFO packed?  That's the only
way these comments of yours make sense ... so for 6-bit data you would send
three bytes of AAAAAABB BBBBCCCC CCDDDDDD?  And for 9-bit you send AAAAAAAA
ABBBBBBB BBCCCCCC CCCDDDDD DDDDEEEE EEEEEFFF FFFFFFGG GGGGGGGH HHHHHHHH?

It doesn't seem to work that way for me.  I'm setting up the sound circuit
to 9-bit at 32kHz and I'm feeding it 8-bit data from ROM [using DMA] and it
sounds just fine.  I can't imagine that it would even be recognizable if it
was expecting 8 lots of 9-bit data per 9 bytes.  As far as I can tell, the
FIFO accepts 8-bit numbers and then either truncates them or extends them to
the correct bit-depth that is set up in the PWM circuit.  In which case, how
could you possibly feed it 9-bit data?

Also, I note that on page 82 of the hardware manual there is a specific
"8 -> 9 bit" convertor.  Look closely.  The 4 legacy sound channels go
through a "4 -> 9 bit" convertor too.  These are then mixed inside the "R/L
selection and addition" and only then must the signal be truncated to under
9 bits.  On page 83 of the hardware manual it is also stated that "Linear
8-bit audio data can be played".  Nothing about 9-bit audio.  Granted, there
is 9-bits of *internal* accuracy, but that's only useful if you're using
DirectSound at 1/2 volume alongside legacy sound at full volume, and who
does that?

I'd love to give you the benefit of the doubt, because you do seem so sure
of yourself, but I can find no evidence to support your theory, and lots of
evidence to support mine.  What code are you using to send these alleged
9-bit samples into the hardware?

=== on the topic of PWM ===

> Uh, no.  While it is true that PWM is a 1-bit signal constructed into
> varying rates, there are absolute scads of logical errors.  If the sound
> quality is equivalent, what's this about testing to see which sounds best?

Testing to see which sounds best is necessary because the ANALOG output
circuitry is a priori non-ideal and probably doesn't adapt when you change
the DSP output rate [anyone know for sure?].  However, the output qualities
are identical, in theory, given ideal analog output stages.  These ideal
analog circuits differ for different sample rates.

All this is quite well documented in several DSP textbooks, but the way in
which theory and practice diverge so quickly is one of the things that makes
DSP a "black art".  I don't like to make incorrect statements, hence my
rider.

Another reason is that if the sample frequency is too low then some legacy
sounds will alias [foldover around the Nyquist frequency] so you may need to
raise the frequency [lower the bit depth] if you are using some of these
sounds.  If the sample frequency now mismatches with the analog filter
cutoff frequency the quality is reduced.

It's a complex system; YMMV.

> And what makes you think that it cannot be predicted what effects sample
> rate and sample depth will have on a sample?

If you know the exact circuitry that Nintendo use in the GBA you can
certainly predict the results to a high degree of accuracy.  But you don't
know, so predicting it would be an impressive feat of reverse engineering.
I'll be fascinated by your results.

I'm just saying, why bother?  The theory is complex and there are only four
settings to try.  There's nothing worse than doing hours [or days] of work
and coming up with the wrong answer when you can find the right answer
empirically in about five minutes.

=== on the topic of dithering ===

> +0.5 what, and -0.5 what?

+/-0.5 units.  I think LSBs is the usual term.  I'm assuming you're working
in fixed-point - say you use 8.24 resolution in your mixer stage.  Then you
have to drop precision to 8 bits, so you add what would be (RND(1) - 0.5) in
BASIC - a random number between -0.5 and +0.5.  This is a number between
0xFF800000 and 0x00800000 in 8.24 fixed-point.

> Why would adding noise make something sound better?  Is this to combat
aliasing?

Not aliasing, no.  Aliasing is when frequencies exist that are higher than
the Nyquist frequency.  This can happen in a variety of situations, and is a
big problem in audio processing.  The word "alias" means "another name" and
this refers to the fact that frequencies above the Nyquist frequency get
"aliased" with frequencies below the Nyquist after sampling or re-sampling.
However, what I am talking about has nothing to do with this at all.

Like I said, it's exactly like dithering on a grayscale image [e.g. if you
only have 4 shades of grey].  I added some more explanation of "why" below.

> Certainly there's something better than randomness.

In the grayscale image case, what looks better than randomness?  Randomness
is good because it doesn't favor one frequency over another - it is "white"
noise.  Any other function is pink noise and will be visible/audible in the
output as pink noise.  Any cyclic function is a non-starter since it
introduces definite frequencies in the output.

> For that matter, if random noise is good, why are uninsulated cables bad?

I didn't say random noise is "good".  I said that when you add 0.5LSB of
noise before quantization the results are better than if you don't.
Dithering requires *exactly* 0.5LSB of noise - any less and the quantization
artifacts show; any more and you are just adding noise to the signal.

> They're not getting very much amplitude compared to the real signal at
all, and though +0.5 has *no*
> *unit* (this is bad, 3rd grade math), I'm assuming you mean against a
signal
> level of one.

When your samples go from -128 to +127 tell me what the "units" are?  LSBs
is the nearest I can get, but it's not an ideal name.

> That said, unless you're a sound engineer, that paragraph is completely
> incomprehensible.  And I'm kind of hesitant to believe that a sine wave,
> when played wihtout noise, sounds liek a square wave when listened to.  Or
> whatever you meant.

OK, I'll exlpain it in a ltitle more detail.

Imagine a sine wave at an amplitude of 1.0 LSB.  What does it sound like?
With only -1.0, 0.0 and 1.0 available, it sounds pretty shitty - like a
squarewave, basically.  Now, we know that a squarewave is a mixture of
harmonic sinewaves which means that the quantization process has introduced
harmonics onto your nice pure sinewave.  This is bad.

By dithering you still only have those three levels avaiable, but the actual
signal jumps around more - and the *average* levels become correct over a
period of time.  The analog filters smooth this out into something close to
an actual sinewave plus noise.  It's pretty clever stuff.  Your ears and
brain can then seperate the sinewave from the noise and hear it as an
independent entity [instead of it being a mess of quantization noise].

It's no different in principle to how your eyes and brain "smooth out" a
dithered image.

There is 0.5LSB of extra noise, true, but there is now far less quantization
noise - and if you experiment you'll quickly determine which sort of noise
is the least agreeable.

With a little imagination you can see that this is exactly how PWM works in
the first place.  I'll leave the details as an exercise to the reader. :-)

> If you mean that the dither pattern has a random component, that's
> different, but those aren't random - tehy're pseudo-random, and in the
case
> of dithering patterns, not very - they have rules regarding neighbors,
etc.
> That's very different than random noise and should not be presented as
such.

Dithering patterns are an approximation to true random dithering.  They are
only used because they are economical in hardware [or software] compared to
a random number generator.  These dithering matrices exhibit periodic
behavior [repetitions] over the screen, which the brain picks up like a shot
if the scene contains large patches of smooth gradients.  It would be like
using a 32-sample noise segment - you'd hear a 1kHz tone [at a 32kHz sample
rate].

Pseudo-random noise is imperceptibly different to true random noise.  32-bit
pseudo-random noise at 44kHz doesn't repeat for 27 hours.  No ear can detect
frequencies that low! :-)  Just using rand() would not be good though, since
that repeats after a second or two.

> Dithering
> is a term used specifically to refer to graphics, especially bitmap
> graphics.  It comes from the old english word, meaning to shiver (merriam
> webster online comes up with that one; the better definition can be found
at
> FOLDOC.org).

Explain why the old English word for shiver is unsuitable for the process of
adding random values to a sound signal?  Seems pretty apt to me.  I imagine
that's why the DSP community chose the term in the first place.  I wasn't
aware of any attempt by the CG community to annex it.

In any case, it's the same function.  Of course it has the same name.

> Now, I'm not claiming to know how people on the inside of the digital
audio
> industry talk about things, but I think it's curious that every single one
> of the pages I come up with uses the phrase "anti-aliasing".

Anti-aliasing is a different thing.  Aliasing in sound refers to the
foldover of higher frequencies than the Nyquist, and anti-aliasing refers to
the removal of such components.  It's very important, hence you will easily
find it on a random selection of DSP-related pages.

> If you have a good way of demonstrating to me
> that the *total* resolution - sample rate and sample depth - is changed by
> this operation, I'll take it.  Do remember, as I keep restating, that the
> data rate is unchanged.

Do you still mean the operation of adding 0.5LSB of noise?  Of course the
total resolution isn't changed.  That's not the point of the operation.  The
point is to preserve the data you have got.  If you don't dither, you're
throwing away information [in the low bits of the samples].  If you dither,
this information is somewhat folded in to the final output samples and the
quality is somewhat improved.

Ed xxx

I'm trying to load 2 different 16 colour palettes for 2 different
sprites in mode 0. I'm using 16 colour mode for the sprites but when
I DMA the sprites and the palettes into VRAM one of the sprites isn't
right. I load one palette like this:

DmaArrayCopy(3, duckt_pal, (0 * 32) + OBJ_PLTT, 32);

and the other simply like this:

DmaArrayCopy(3, square_pal, (1 * 32) + OBJ_PLTT, 32);

But the sprites both seem to use the first palette. How do you assign
palette 1 to a sprite? Thanks in advance.

Hi Ben,

Ben Smith wrote:
>
>     For the game I'm currently writing, I want to have an
> uninitialized 80k array in EWRAM. The problem I'm having is
> that if I just declare an 80k array, it's placed in the default
> BSS section

  Yes, this is an inherent limitation with GCC:
     http://www.devrs.com/gba/files/gbadevfaqs.php#VarSections

> (IWRAM) which is too small for 80k. When I declare __attribute__
> ((section ".ewram")) for the array, it works, but my gba file is
> created with 80k of zeros at the end of it, because it's considered
> initialized data. Is there any way that I can have an EWRAM BSS
> section? How much modification of the lnkscrpt/crt0.s files would
> this require?

  Yes, you could do that. Before attempting that you would need to
decide if the data section (initialized data) would also go into EWRAM
or stay in IWRAM. You can use the AT command in the lnkscript to put
the BSS anywhere you want. I'd help but I've got more than I can handle
at the moment.

  The drawback would be that all of your uninitialized variables would
now be in EWRAM which will slow down possibly critical routines which
use ram variables, if you have any. One suggestion would be to use a
pointer, instead, for the arrays that require use of EWRAM. This
suggestion is also in the link above:

  u8 *MyArray = (u8 *)0x2000000; // ewram start
  MyArray[0] = 1;

  Jeff

For the game I'm currently writing, I want to have an uninitialized 80k
array in EWRAM. The problem I'm having is that if I just declare an 80k array,
it's placed in the default BSS section (IWRAM) which is too small for 80k. When
I declare __attribute__ ((section ".ewram")) for the array, it works, but my gba
file is created with 80k of zeros at the end of it, because it's considered
initialized data. Is there any way that I can have an EWRAM BSS section? How
much modification of the lnkscrpt/crt0.s files would this require?

Ben


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