On Monday 31 March 2003 22:15, Morten Pedersen wrote:
> but that's completely retarded. that means (and i just tested this to be
> true) the following code ends up with '1' in r12.
>
>   mov r10,#0x00000000
>   mov r11,#0x00000000
>   subs r12,r10,r11
>   adc r12,r10,r11

the last one should be ADD not ADC (which adds the carry => 1) :=)

gpz

but that's completely retarded. that means (and i just tested this to be
true) the following code ends up with '1' in r12.

   mov r10,#0x00000000
   mov r11,#0x00000000
   subs r12,r10,r11
   adc r12,r10,r11




----- Original Message -----
From: "Damian Yerrick" <d_yerrick@...>
To: <gbadev@yahoogroups.com>
Sent: Monday, March 31, 2003 8:28 AM
Subject: [gbadev] Re: The carry flag


>
> From what I've read, the carry flag on the ARM architecture seems
> to operate under subtraction like the one on the 6502 architecture:
> 0 for borrow and 1 for no borrow.  The 6502 does subtraction like
> this:

I changed the meaning of the symbols __sp_usr and __sp_int in R5-Beta-2.
Instead of absolute addresses defined in the linker script, they are now
actual pointers stored in the ROM.

The programmer can provide their own definition of these symbols, but if
you do not, then defaults will be used.  I achieved this by making them
weak symbols.  A weak symbol points to an actual value in memory, but if a
none weak symbol is linked, then that value is used without causes a
'multiple definition' error.

This is far preferable to editing the linkscript in order to change the
stack location.  However, it may also break things, because someone using
a custom link script may not also be using a custom crt0 to go with it.
Anyone using a custom link script with the default crt0 of devkit advance
will have a broken program.

To set the stack location using devkit advance R5-beta-2:

const int __sp_usr = 0x02003f000;
const int __sp_int = 0x02003ffff;

I am thinking of changing the names of these symbols, perhaps to
__sp_usr_init and __sp_int_init because they are the initial values
(changing them after initialization will not change the stack location).

Hmm, I could then make the defaults be equal to __sp_usr and __sp_int,
which would preserve compatiblity.

I guess this is just a heads up, in case I broke something.  Compatibility
will be restored next release.

I really need to get my devkitadv library out, because this sort of
symbol renaming is something I want to be able to do without breaking
anything.

The library would just have the macros:

USR_STACK_BASE(address);
INT_STACK_BASE(address);

Something like that.

--
            The Phoenix - NekoCo - The Artistic Intuition Company
DevKitAdvance*MirrorReflex*Teapot*PhoenixQuake*Caelius*Zen-X*InfiniteRealms

A sh4 toolchain (dreamcast), and arm toolchain(AICA and GBA), and x86
toolchain

I never had a problem, since I always did it this way, I like to be
explicit, and exactly specifying which executable to run keeps things
clear, at least in my mind :-)

Furthermore, it only needs to be written once, and I needed the include
file anyway.
That include file is also different depending wheter you are compiling
under cygwin or linux, we used both in the company.

HTH,
Willem


-----Original Message-----
From: Jason Wilkins [mailto:fenix@...]
Sent: 31 March 2003 15:49
To: gbadev@yahoogroups.com
Subject: RE: [gbadev] GCC ix86 & ARM Coexisting?


On Mon, 31 Mar 2003, Willem Kokke wrote:

> I have the same setup and solved it like this:
> [solution snipped]

Wow, what kind of problem were you having that you had to use the full
path to each tool?






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

On Mon, 31 Mar 2003, Willem Kokke wrote:

> I have the same setup and solved it like this:
> [solution snipped]

Wow, what kind of problem were you having that you had to use the full
path to each tool?

On Mon, 31 Mar 2003, Greg Wogan-Browne wrote:

>
> Hi
>
> I've installed Cygwin, which includes GCC on my WinXP box, and have
> successfully used it to compile PC programs. I want to keep this state of
> affairs, but I also want to be able to compile AGB programs. Installing
> DevKitAdv means changing paths and other env vars which breaks my existing
> Cygwin install (as far as I know).

Which version of DevKit Advance are you using?  If is R4, then everything
should work just fine.  Unfortunately, this is not somethin I have tested
for R5-beta.

R5-Beta will work without environment variables if you install it into
c:\devkitadv-r5-beta.  Just now I tested it in cygwin, and it appears
to work fine (at least, it finds its include directories, which was the
problem before).

R5-beta-2 is relocatable, so all it needs is for you to set the path for
it to work.  You may want to wait for that if you cannot install into
c:\devkitadv-r5-beta.  I had to work around a bug/feature in msys to get
it to work, but it does.  R5-beta-2 should be uploaded by this after noon
if I do not find any serious problems with it.

> Greg Wogan-Browne
> wogan @ iinet.net.au

I have the same setup and solved it like this:

I have this in a include file which I include in all my makefiles, which
contains:

DEVKITADV_DIR = $(GBADEV_DIR)/devkitadv

CC         =   $(DEVKITADV_DIR)/bin/arm-agb-elf-gcc
AS         =   $(DEVKITADV_DIR)/bin/arm-agb-elf-as
AR      =   $(DEVKITADV_DIR)/bin/arm-agb-elf-ar
LD      =   $(DEVKITADV_DIR)/bin/arm-agb-elf-ld
CPP        =   $(DEVKITADV_DIR)/bin/arm-agb-elf-cpp
OBJCOPY    =   $(DEVKITADV_DIR)/bin/arm-agb-elf-objcopy

And then in the makefile I just do:

include /gbadev/Makefile_win_gcc3.inc

$(TARGET_BIN): $(TARGET_ELF)
	 $(OBJCOPY) -v -O binary $< $@

$(TARGET_ELF): $(.OFILES) $(LIBGCCDIR)/crtbegin.o $(LIBGCCDIR)/crtend.o
Makefile data/libdata.a
	 $(CC) -g -o $@ $(.OFILES) $(LIBGCCDIR)/crtbegin.o
$(LIBGCCDIR)/crtend.o $(LDFLAGS)

Offcourse this are just snippets, but you get the idea I hope

HTH,
Willem



-----Original Message-----
From: Greg Wogan-Browne [mailto:wogan@...]
Sent: 31 March 2003 10:59
To: gbadev@yahoogroups.com
Subject: [gbadev] GCC ix86 & ARM Coexisting?



Hi

I've installed Cygwin, which includes GCC on my WinXP box, and have
successfully used it to compile PC programs. I want to keep this state
of
affairs, but I also want to be able to compile AGB programs. Installing
DevKitAdv means changing paths and other env vars which breaks my
existing
Cygwin install (as far as I know).

Can anyone give me some hints on how to set this up gracefully so that
they
both co-exist with eachother nicely? Cygwin includes some GCC libraries
for
ARM-AGB-ELF, which leads me to think that there is a way of getting
Cygwin's GCC to compile AGB programs.

Any help or links to good documentation would be appreciated,

Greg Wogan-Browne
wogan @ iinet.net.au






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

Hi

I've installed Cygwin, which includes GCC on my WinXP box, and have
successfully used it to compile PC programs. I want to keep this state of
affairs, but I also want to be able to compile AGB programs. Installing
DevKitAdv means changing paths and other env vars which breaks my existing
Cygwin install (as far as I know).

Can anyone give me some hints on how to set this up gracefully so that they
both co-exist with eachother nicely? Cygwin includes some GCC libraries for
ARM-AGB-ELF, which leads me to think that there is a way of getting
Cygwin's GCC to compile AGB programs.

Any help or links to good documentation would be appreciated,

Greg Wogan-Browne
wogan @ iinet.net.au

--- In gbadev@yahoogroups.com, "Morten Pedersen" <escapekey@s...>
wrote:
> I'm sitting executing singular assembler instructions and I'm
getting some quite spectacular results!
>
>   mov r10,#0x7f000000
>   mov r11,#0x1fc00000
>   adds r12,r10,r11,LSL #2
> (0x7f00_0000+0x7F00_0000=0xfe00_0000), carry flag set !?!?
>
>   mov r10,#0xC0000000
>   mov r11,#0x10000000
>   subs r12,r10,r11,LSL #2
> (0xC000_0000-0x4000_0000=0x8000_0000), sign bit correctly set, but
carry flag as well!?

From what I've read, the carry flag on the ARM architecture seems
to operate under subtraction like the one on the 6502 architecture:
0 for borrow and 1 for no borrow.  The 6502 does subtraction like
this:

   Rd = Rs - Rt + (Carry - 1)

(On the 6502, Rs and Rd are both the A register, and Rt holds the
data most recently loaded from memory.)

Then you can see how 1 represents borrow nothing and 0 represents
borrow 1.  The reasoning behind this lies in how it's implemented
in hardware:

   Rd = Rs - Rt - 1 + Carry
   Rd = Rs + (-Rt - 1) + Carry

But by the properties of two's complement, (-x - 1) equals (~x),
that is, x XOR -1.  Thus, subtraction is implemented in 6502
and ARM hardware as addition with inverted second operand:

   Rd = Rs + (~Rt) + Carry

On ARM, a SUB (rather than SBC) overrides the adder's carry
input with 1 when performing the "subtraction" in the ALU.
So your 0 - 0 example works thus:

   Rd = Rs + (~Rt) + Carry
      = 0  + (~0)  + 1
      = 0 + 0xffffffff + 1
      = 0x100000000
      = 0, carry 1 (that is, borrow 0)

The only difference between SUB/SBC and RSB/RSC lies in which
operand gets inverted before addition.  (RSB and RSC on ARM are
instructions, but RSC on 6502 was a macro for 'EOR #$FF; ADD', and
SUB and RSB were macros for 'SEC; SBC' and 'SEC; EOR #$FF; ADD'.)

--
Damian

P.S. A big reason I got into console homebrew development was
because my Apple IIe asm skills transferred cleanly to the NES.

The carry flag for a SUBS instruction on the ARM is inverse to many
processors (but the same as the 6502) in that it is set if there's nothing
to carry.

So the subtract with carry instruction

SBC r1,r2,r3

effectively does

r1 = r2 - r3 - (1- carry)

Cheers
Dave


----- Original Message -----
From: "Morten Pedersen" <escapekey@...>
To: <gbadev@yahoogroups.com>
Sent: Monday, March 31, 2003 1:01 AM
Subject: [gbadev] The carry flag


> I'm sitting executing singular assembler instructions and I'm getting some
quite spectacular results!
>
>   mov r10,#0x7f000000
>   mov r11,#0x1fc00000
>   adds r12,r10,r11,LSL #2
> (0x7f00_0000+0x7F00_0000==0xfe00_0000), carry flag set !?!?
>
>   mov r10,#0xC0000000
>   mov r11,#0x10000000
>   subs r12,r10,r11,LSL #2
> (0xC000_0000-0x4000_0000==0x8000_0000), sign bit correctly set, but carry
flag as well!?
>
>   mov r10,#0x00000000
>   mov r11,#0x40000000
>   subs r12,r10,r11,LSL #2
> (0x0000_0000-0x0000_0000==0x0000_0000), zero bit correctly set, carry flag
here we go again
>
> here's the kicker though
>
>   mov r10,#0x00000000
>   mov r11,#0x00000000
>   subs r12,r10,r11,LSL #2
>
> (0x0000_0000-0x0000_0000==0x0000_0000), zero bit correctly set, and yet
again, carry bit what the f*ck?
>
>
> Can anyone reproduce, or did I miss something fundamental about the carry
bit?
>
>
>
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

One Man Band is pleased to announce the release of Converter of Graphics
(CoG), its latest image conversion tool for the Gameboy Advance, which is
now available for immediate downloading.

CoG is a command-line tool that easily integrates into any 'make' process.
It can convert images to source code, raw data and even directly to an
object file. Other features include: header file creation, tile
optimization, image quantizing, data compression and direct-to-ROM
exporting.

CoG is not just for programmers! By exporting directly to a ROM, artists can
quickly check to see how the image looks on an actual Gameboy Advance.
Simply convert the image and specify the ROM exporting option, flash the
newly-created ROM to a cartridge, power on your Gameboy Advance and view
your image. It's that simple!

Download CoG today and see how quick and easy it is to convert all of your
images.

CoG - the only Gameboy Advance image converter you'll ever need.

http://www.onemanband.com

I'm sitting executing singular assembler instructions and I'm getting some quite
spectacular results!

   mov r10,#0x7f000000
   mov r11,#0x1fc00000
   adds r12,r10,r11,LSL #2
(0x7f00_0000+0x7F00_0000=0xfe00_0000), carry flag set !?!?

   mov r10,#0xC0000000
   mov r11,#0x10000000
   subs r12,r10,r11,LSL #2
(0xC000_0000-0x4000_0000=0x8000_0000), sign bit correctly set, but carry flag as
well!?

   mov r10,#0x00000000
   mov r11,#0x40000000
   subs r12,r10,r11,LSL #2
(0x0000_0000-0x0000_0000=0x0000_0000), zero bit correctly set, carry flag here
we go again

here's the kicker though

   mov r10,#0x00000000
   mov r11,#0x00000000
   subs r12,r10,r11,LSL #2

(0x0000_0000-0x0000_0000=0x0000_0000), zero bit correctly set, and yet again,
carry bit what the f*ck?


Can anyone reproduce, or did I miss something fundamental about the carry bit?

I think I figured it out.  I wrote a small program to see how the shell
changes the command line arguments.  It appears that the shell translates
paths before passing them, and in doing so it removes any relative path
parts, e.g., /foo/../../bar becomes c:/msys/1.0/bar

I am really begining to think that I need to use Linux to build devkitadv
for windows.

I have traced the problems with relocating dka5b to the paths being
changed from relative to absolute somewhere before they are compiled into
cpp (c pre-processor).  I think this is due to some mechanism which
translates msys paths into win32 paths.

This is complicated:

All directories that can be relocated as found relative to a directory
called the gcc_toodir which is:

/devkitadv-r5-beta/lib/gcc-lib/arm-agb-elf/3.2.2

So, the include directory, relative to that is

/devkitadv-r5-beta/lib/gcc-lib/arm-agb-elf/3.2.2/../../../../include

When the compiler notices that the compiler is not in the original
location, it replaces the gcc_tooldir part of the path with the new
location:

/newlocation/lib/gcc-lib/arm-agb-elf/3.2.2/../../../../include

What is going wrong?

Somewhere, I believe it is in msys, the gcc_toordir gets translated into a
windows path with a drive letter, which should be:

c:/devkitadv-r5-beta/lib/gcc-lib/arm-agb-elf/3.2.2

And the include directory SHOULD get translated into:

c:/devkitadv-r5-beta/lib/gcc-lib/arm-agb-elf/3.2.2/../../../../include

BUT, the translation is getting rid of the relative part and making it
completely absolute:

c:/devkitadv-r5-beta/include

This will not get relocated because it does not begin with the original
gcc_toodir.  Basically, if the compiler sees the original gcc_tooldir at
the beginning of a path it replaces it with the real path, that is why
there is that ridiculous looking ../../../..

If the path was correct it would make it:

c:/newlocation/lib/gcc-lib/arm-agb-elf/3.2.2/../../../../include

Argh, I have still left out a lot of details.  This requires a lot of
experience with gcc source code and build process to understand.  I'm just
hoping that someone else has as much as me (which is a lot, but still
pretty inadequate).

Anyone have any idea at what point this a path would be translated from
the msys /c/devkitadv-r5-beta into c:/devkitadv-r5-beta?

On Sat, 29 Mar 2003, Damian Yerrick wrote:

> Your tone seemed to imply that you have, in Bugzilla terminology,
> resolved the include directory issue as WONTFIX.

Actually my tone was RTFM ^_^, because I think I mentioned it everytime I
posted about the beta.

> > What I did not test was the ability to use filenames to put
> > stuff in iwram.
>
> Which is exactly the technique I used, with an object file called
> "siw.text.iwram.o".  (The "siw" part stands for "simplest program
> containing an iwram segment".)

This is fixed now, and will be incorporated into the next release, which
will be this weekend.

You could also use DarkFader's GbaTool (http://www.darkfader.net) rom to put a
bunch of mb images
into 1 rom and flash that to your cart. From there, it's just a matter
of using a menu to pick which one.

Mike "BigRedPimp" Parks
Berzerk Legends project maintainer - http://berzerk.pocketheaven.com/

Friday, March 28, 2003, 2:00:48 PM, Rasmus Bonnedal wrote:

RB> Hi all!

RB> I have recently purchased a Flash 2 Advance highspeed linker cable, and it
RB> works great to write the flash memory with the program from
RB> www.flash2advance.com. The program obviously begins with sending a
RB> flashing program to the GBA by using multiboot, but the program does not
RB> support uploading other mb images.

RB> Is it possible to use another program with the f2a cable in order to
RB> upload multiboot images?

RB> Thanks in advance / Rasmus



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

--- In gbadev@yahoogroups.com, Jason Wilkins <fenix@i...> wrote:
> On Fri, 28 Mar 2003, Damian Yerrick wrote:
>
> > Root directories can become full...
>
> It is just that I would rather have DevKit Advance out now

Your tone seemed to imply that you have, in Bugzilla terminology,
resolved the include directory issue as WONTFIX.  But if you're
implying only that you didn't consider the issue a beta blocker,
I understand your motives.

> And it is really obvious when it takes 10 seconds to objcopy
> instead of 0.

It wasn't obvious on my system, but that may have just been because
I'm used to the Cygwin-based Devkit Advance 4 distribution, which
takes a while to objcopy even small files.

> What I did not test was the ability to use filenames to put
> stuff in iwram.

Which is exactly the technique I used, with an object file called
"siw.text.iwram.o".  (The "siw" part stands for "simplest program
containing an iwram segment".)

--
Damian

Currently their are no way to use a F2A cable to upload mb files.

However, you can make a xboot cable use a 25pin connector and a link cable.

Jacob Kjær



>From: Rasmus Bonnedal <d99rambo@...>
>Reply-To: gbadev@yahoogroups.com
>To: gbadev@yahoogroups.com
>Subject: [gbadev] Flash 2 Advance cable and multiboot?
>Date: Fri, 28 Mar 2003 20:00:48 +0100 (MET)
>
>Hi all!
>
>I have recently purchased a Flash 2 Advance highspeed linker cable, and it
>works great to write the flash memory with the program from
>www.flash2advance.com. The program obviously begins with sending a
>flashing program to the GBA by using multiboot, but the program does not
>support uploading other mb images.
>
>Is it possible to use another program with the f2a cable in order to
>upload multiboot images?
>
>Thanks in advance / Rasmus
>
>


_________________________________________________________________
Tag MSN Hotmail med dig på mobilen http://www.msn.dk/mobile

On Fri, 28 Mar 2003, Damian Yerrick wrote:

> Root directories can become full...

I didn't mean to be so short with you.  It is just that I would rather
have DevKit Advance out now and being tested (a great success so far)
instead of banging my head on one little obscure problem that I can easily
work around for now.

After sitting on it for 2 years, I didn't want to delay it another week.

> It appears to be triggered by a non-empty .iwram segment.

No, I have tested that thoroughly.  And it is really obvious when it takes
10 seconds to objcopy instead of 0.

What I did not test was the ability to use filenames to put stuff in
iwram.  That is what triggers one of the problems.  If you do not use
*.iram.o in order to put stuff in iwram, then we have a different problem.

Hi all!

I have recently purchased a Flash 2 Advance highspeed linker cable, and it
works great to write the flash memory with the program from
www.flash2advance.com. The program obviously begins with sending a
flashing program to the GBA by using multiboot, but the program does not
support uploading other mb images.

Is it possible to use another program with the f2a cable in order to
upload multiboot images?

Thanks in advance / Rasmus

--- In gbadev@yahoogroups.com, Jason Wilkins <fenix@i...> wrote:
> On Thu, 27 Mar 2003, Damian Yerrick wrote:
>
> > To duplicate the problem, move the install directory.
>
> Do not move the install directory!

Root directories can become full, and not all users have write
access to C:\ (perhaps only to \Documents and Settings\username).
The solution of putting the install directory in its normal place
is acceptable to me personally, but you'll probably need to add
the following to the system requirements:

* One free entry in the root directory of drive C:
* Permission to write to drive C: during installation

> > I'm still thinking about how to narrow down the cause of the
> > 16 MB of zeroes in a binary that I discovered
>
> Use objdump -x to find out which section has an incorrect LMA
> address.  LMA should start at 0 and work up to the correct size
> of your ROM, but in your case one of the sections is being put
> way too high (instead of right after the previous section), so
> objcopy fills in the space in between with zeros. Tell me which
> section is the problem.

I don't know what to make of this:

--- begin siw.objdump.txt ---

s.elf:     file format elf32-littlearm
s.elf
architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x02000000

Program Header:
     LOAD off    0x00008000 vaddr 0x02000000 paddr 0x02000000 align
2**15
          filesz 0x00000350 memsz 0x00000350 flags rwx
     LOAD off    0x00010000 vaddr 0x03000000 paddr 0x02000350 align
2**15
          filesz 0x00000008 memsz 0x0000003c flags rw-
     LOAD off    0x00010040 vaddr 0x03000040 paddr 0x03000040 align
2**15
          filesz 0x00000000 memsz 0x00000024 flags rw-
private flags = 6: [interworking enabled] [APCS-32] [FPA float format]
[has entry point]

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         00000314  02000000  02000000  00008000  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   1 .init         00000014  02000314  02000314  00008314  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   2 .fini         00000010  02000328  02000328  00008328  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   3 .rodata       00000000  02000338  02000338  00010040  2**0
                   CONTENTS
   4 .eh_frame     00000004  02000338  02000338  00008338  2**2
                   CONTENTS, ALLOC, LOAD, DATA
   5 .ctors        00000008  0200033c  0200033c  0000833c  2**2
                   CONTENTS, ALLOC, LOAD, DATA
   6 .dtors        00000008  02000344  02000344  00008344  2**2
                   CONTENTS, ALLOC, LOAD, DATA
   7 .jcr          00000004  0200034c  0200034c  0000834c  2**2
                   CONTENTS, ALLOC, LOAD, DATA
   8 .rom          00000000  02000350  02000350  00010040  2**0
                   CONTENTS
   9 .data         00000008  03000000  02000350  00010000  2**2
                   CONTENTS, ALLOC, LOAD, DATA
  10 .iwram        00000034  03000008  03000008  00010008  2**0
                   CONTENTS, ALLOC, LOAD, DATA
  11 .iwram0       00000000  0300003c  0300003c  00010040  2**0
                   CONTENTS
  12 .iwram1       00000000  0300003c  0300003c  00010040  2**0
                   CONTENTS
  13 .iwram2       00000000  0300003c  0300003c  00010040  2**0
                   CONTENTS
  14 .iwram3       00000000  0300003c  0300003c  00010040  2**0
                   CONTENTS
  15 .iwram4       00000000  0300003c  0300003c  00010040  2**0
                   CONTENTS
  16 .iwram5       00000000  0300003c  0300003c  00010040  2**0
                   CONTENTS
  17 .iwram6       00000000  0300003c  0300003c  00010040  2**0
                   CONTENTS
  18 .iwram7       00000000  0300003c  0300003c  00010040  2**0
                   CONTENTS
  19 .iwram8       00000000  0300003c  0300003c  00010040  2**0
                   CONTENTS
  20 .iwram9       00000000  0300003c  0300003c  00010040  2**0
                   CONTENTS
  21 .bss          00000024  03000040  03000040  00010040  2**5
                   ALLOC
  22 .ewram        00000000  0200038c  0200038c  00010040  2**0
                   CONTENTS
  23 .ewram0       00000000  0200038c  0200038c  00010040  2**0
                   CONTENTS
  24 .ewram1       00000000  0200038c  0200038c  00010040  2**0
                   CONTENTS
  25 .ewram2       00000000  0200038c  0200038c  00010040  2**0
                   CONTENTS
  26 .ewram3       00000000  0200038c  0200038c  00010040  2**0
                   CONTENTS
  27 .ewram4       00000000  0200038c  0200038c  00010040  2**0
                   CONTENTS
  28 .ewram5       00000000  0200038c  0200038c  00010040  2**0
                   CONTENTS
  29 .ewram6       00000000  0200038c  0200038c  00010040  2**0
                   CONTENTS
  30 .ewram7       00000000  0200038c  0200038c  00010040  2**0
                   CONTENTS
  31 .ewram8       00000000  0200038c  0200038c  00010040  2**0
                   CONTENTS
  32 .ewram9       00000000  0200038c  0200038c  00010040  2**0
                   CONTENTS
  33 .comment      0000009c  00000000  00000000  00010040  2**0
                   CONTENTS, READONLY
--- end siw.objdump.txt ---

In a program without code in IWRAM, I get this:

  10 .iwram        00000000  0300000c  0300000c  00010020  2**0
                   CONTENTS

But in a program with code in IWRAM, I get this:

  10 .iwram        00000034  03000008  03000008  00010008  2**0
                   CONTENTS, ALLOC, LOAD, DATA

It appears to be triggered by a non-empty .iwram segment.

And apparently, what's being put 16 MB into the binary is not
code or data but rather 10 bytes of nulls followed by a string:
"GCC: (GNU) 3.2.2 (DevKit Advance Release 5 (Panda)"

Do you want me to send you the object files in question so you can
debug what's happening?

--
Damian

> The primary difference between simplest (from the previous bug
> report) and siw (here) is that siw includes some code in IWRAM.
> Link script bug?  Definitely a blocker for any GBA program with
> a mixer.

In the link script, I had changed the line:

*iwram.* (.text)

to:

*.iwram.o

This doesn't work correctly, so I changed it to:

*iwram.o (.text .data)

With that, you can include data in iwram as well.

I need to do some more testing on how this interacts with the other ways
to put stuff in iwram.

--
            The Phoenix - NekoCo - The Artistic Intuition Company
DevKitAdvance*MirrorReflex*Teapot*PhoenixQuake*Caelius*Zen-X*InfiniteRealms

On Thu, 27 Mar 2003, Damian Yerrick wrote:

> To duplicate the problem, move the install directory.

Do not move the install directory!  This is a bug I knew about before I
released it.  Put the standard C header file paths on your command line
using the -I option as a work around if you must more the install dir.

> 1. Compute the path of the folder that contains the running exe,
>    based on argv[0].
> 2. Set CPATH and CPLUS_PATH to (exe folder)/../include

No way, I'm not touching it.  Besides, it does this already, but for some
reason it just is not doing it for the include dirs (it finds the programs
and library files, but the include paths get hosed).

> I'm still thinking about how to narrow down the cause of the 16 MB
> of zeroes in a binary that I discovered when trying to compile TOD.

Use objdump -x to find out which section has an incorrect LMA address.
LMA should start at 0 and work up to the correct size of your ROM, but in
your case one of the sections is being put way too high (instead of right
after the previous section), so objcopy fills in the space in between with
zeros.  Tell me which section is the problem.

The previous stable version of Devkit Advance compiled the
following source code correctly (it turns the screen turquoise
in VBA) and produced a 9 KB binary.  The Devkit Advance R5 beta,
on the other hand, produced a 16 MB binary that clearly does not
fit in the GBA's memory.

--- begin siw.c ---
typedef unsigned short u16;

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

void set_palram_green(void)
{
   PALRAM[0] = RGB( 0,31,15);
}
--- end siw.c ---

--- begin sew.c ---
typedef unsigned short u16;
#define LCDMODE (*(volatile u16 *)0x04000000)
void set_palram_green(void);  /* a function in iwram */

int __gba_multiboot;

int main(void)
{
   LCDMODE = 0;
   set_palram_green();

   while(1) ;
}
--- end sew.c ---

--- begin mk.bat ---
@echo off
gcc -Wall -O -marm -mthumb-interwork -o siw.text.iwram.o -c siw.c
if errorlevel 1 goto end
gcc -Wall -O -mthumb -mthumb-interwork -o s.elf sew.c siw.text.iwram.o
if errorlevel 1 goto end
objcopy -O binary s.elf siw.mb
:end
--- end mk.bat ---

The primary difference between simplest (from the previous bug
report) and siw (here) is that siw includes some code in IWRAM.
Link script bug?  Definitely a blocker for any GBA program with
a mixer.

--
Damian

--- In gbadev@yahoogroups.com, Jason Wilkins <fenix@i...> wrote:
> The person having the problem with dka and mingw not working
> together, even after removing CPATH and CPLUS_PATH from the rc.bat
> file, should give me a beter idea of how to duplicate the problem.

To duplicate the problem, move the install directory.

To try to fix the problem, change GCC so that it does the
following if CPATH is not set:

1. Compute the path of the folder that contains the running exe,
    based on argv[0].
2. Set CPATH and CPLUS_PATH to (exe folder)/../include


I'm still thinking about how to narrow down the cause of the 16 MB
of zeroes in a binary that I discovered when trying to compile TOD.

--
Damian

After examining the problem, it seems like DevKit Advance R5 Beta works
fine without the CPATH and CPLUS_PATH environment variables.  The problems
seem to pop up when you move the install directory (c:/devkitadv-r5-beta).
All the programs and libs are OK, but the headers are not found.

The person having the problem with dka and mingw not working together,
even after removing CPATH and CPLUS_PATH from the rc.bat file, should give
me a beter idea of how to duplicate the problem.

Anybody else running the beta can try removing the CPATH and CPLUS_PATH
variables from the rc.bat file and see if the compiler still works.

--
            The Phoenix - NekoCo - The Artistic Intuition Company
DevKitAdvance*MirrorReflex*Teapot*PhoenixQuake*Caelius*Zen-X*InfiniteRealms

I read:
> BIOS has the ability to convert MIDI notes

there is a midi->frequency BIOS function IIRC, but I never used it,
I use my own lookuptable generated by
(8.17579891564 * exp(.0577622650 * notenum))
this way I can also switch my lookuptables for different tunings or
settings for individual soundchannels but YMMV

> and play music but I haven't

no sorry, it won't play any music for you

> seen it documented anywhere.  Is there a website where someone describes
> this functionality?  Or someone has some sample code?

http://www.work.de/nocash/gbatek.htm#biossoundfunctions

HTH

x

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

We've been here before (I myself have asked previously) to no avail.  I've
collected together some sources that I was planning to use when I finally
get round to putting something together (if I do it, I'll release a
tron/pong test program but I wouldn't hold your breath).  The best looking
(but so far I've only read it, not used it) code is in the sgade
(http://www.suddenpresence.com/sgade/) libraries.  If you download that and
install it, there's a source for each submodule, including multiplayer.
It's well laid out code which shows you what registers to set, interrupts to
call etc.

Hope this helps (if not directly).

Chris
   -----Original Message-----
   From: Kurt Mahan [mailto:kmahan@...]
   Sent: 25 March 2003 18:16
   To: gbadev@yahoogroups.com
   Subject: [gbadev] Multiplayer Code


   What are some source examples of using the multiplayer game link?

   Thanks!

   Kurt
   kmahan@...


         Yahoo! Groups Sponsor
               ADVERTISEMENT




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

A sound related question.  I've searched around and found plenty of
docs on the sound hardware (thanks!).  I've seen mentioned that the
BIOS has the ability to convert MIDI notes and play music but I haven't
seen it documented anywhere.  Is there a website where someone describes
this functionality?  Or someone has some sample code?

Thanks,

Kurt
kmahan@...

On Tue, 25 Mar 2003, Damian Yerrick wrote:

> First of all, the beta produces multiboot-exclusive ROMs

My crt0 was properly detecting that it was loade into ROM instead of
ewram, but the addresses it was using to copy itself to ewram were wrong.

Sorry I forgot to test this.  It is kinda dumb of me since I rewrote the
code to make it easier (for me) to understand.  Now, if only VBA's
disassembly window allowed you to set breakpoints... (stepping through a
copy loop takes a while)

> === PROBLEM 2: Getting MinGW and Devkit Advance to Coexist ===

This is because I have to set environment variables in order relocate
devkitadv from its build prefix directory.

> How can I get MinGW's native gcc and arm-agb-elf-gcc to coexist?

I'll see if there is not something else I can do which will not effect
other gcc compilers.

I have not been able to figure out what mingw and cygwin do in order to be
relocatable.

--
            The Phoenix - NekoCo - The Artistic Intuition Company
DevKitAdvance*MirrorReflex*Teapot*PhoenixQuake*Caelius*Zen-X*InfiniteRealms