hiya :)
just started on this whole gba thing, but it feels a lot like good old mode 13h
(ahh- nostalgia!).
so, anyway, i'm in gfx mode 3. i've been coding a simple little demo involving a
bunch of vertical lines.
if it was mode 13h, i'd do it like this:
main_loop:
update positions of lines
draw new lines
wait for vsync
erase old lines
goto main_loop
but this doesn't work on the GBA. i get all kinds of wierd things happening to
my lines (on both Mappy and iGBA). It seems to be that the tops of the lines are
1 pixel further along than they should be. I've changed my drawVLine routine so
much, and i am now simply plotting individual pixels (euch!).
i think it's connected with the vsync, because moving the waitNextVSync()
changes the effect.
again, i've used several routines for waiting for the vsync, and i'm currently
using:
void waitNextVBlank ()
{
while((*((volatile u16 *)0x04000004) & (1<<0)));
while(!(*((volatile u16 *)0x04000004) & (1<<0)));
}
does anyone have any ideas?
cheers-
alex :)
Just like I promise. GASS Lite SDK is available for download from:
http://www.fireworks.atomnet.pl
GASS Lite is a Amiga MOD player that can be used for free
in non-commercial products.
Supports 4-16 channels. All effects are played correctly. Playing
4ch MOD uses 30% of CPU time.
-------------------- [POLBOX - REKLAMA] ------------------------
SprawdŸ swoje bezpieczeñstwo w Sieci
Zabezpiecz siê ! www.symantec.com/region/pl/product/nis2001.html
----------------------------------------------------------------
I had a similar problem in wanting to compile ARM code with GCC. I had all
manner of problems, but with the latest devkitadvance (GCC 3.0.1 support)
all works very nicely. It supports the -mthumb and -marm command line option
to compile the appropriate code code.
Cheers
Aaron
-----Original Message-----
From: Dickinson, Vince [mailto:vinced@...]
Sent: Saturday, 1 September 2001 6:28 a.m.
To: Gbadev (E-mail)
Subject: [gbadev] arm & thumb gcc together
I want to compile some code with arm gcc and some with thumb gcc. I have
both 2.95 compilers installed and working but I can't figure out how to use
them together. For the life of me I can't find where CC =
/cygnus/thumbelf-000512/bin/thumb-elf-gcc (or whatever it happens to be) is
defined for the makefile. Or should I just go to gcc 3.0x which apparently
supports both with the same compiler. I've been using thumb gcc and
everything is smooth but now I want to compile a C file for ARM and link it
in. How is everyone else doing arm/thumb combinations - or are you just
doing all arm code in assembler anyways?
Thanks,
Vince
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/
I want to compile some code with arm gcc and some with thumb gcc. I have
both 2.95 compilers installed and working but I can't figure out how to use
them together. For the life of me I can't find where CC =
/cygnus/thumbelf-000512/bin/thumb-elf-gcc (or whatever it happens to be) is
defined for the makefile. Or should I just go to gcc 3.0x which apparently
supports both with the same compiler. I've been using thumb gcc and
everything is smooth but now I want to compile a C file for ARM and link it
in. How is everyone else doing arm/thumb combinations - or are you just
doing all arm code in assembler anyways?
Thanks,
Vince
> > Mode 5, that's the mode that only uses part of the screen, right? And
on
> > hardware its centered, right? I'm wondering if you are saying that
you're
>
> Noo, top left.
Ahh okay well that actually makes the original post make more sense then --
I was trying to throw in an emulator where none needed to be.
>
> Unless that's changable via scroll registers or something... not looked
into
> it.
>
> Would be interesting if you could...
>
I'm fairly sure you can't, and I think that might be what he's trying to do.
> Mode 5, that's the mode that only uses part of the screen, right? And on
> hardware its centered, right? I'm wondering if you are saying that you're
Noo, top left.
Unless that's changable via scroll registers or something... not looked into
it.
Would be interesting if you could...
--Jim
Mode 5, that's the mode that only uses part of the screen, right? And on
hardware its centered, right? I'm wondering if you are saying that you're
trying to move that somewhere. Do some emulators place the smaller display
region in the upper corner instead of centering it? If so, perhaps you are
trying to move that to the center of the screen?
That's a lot of speculation on my part as to what you're saying the problem
might be. If I'm right, I'm pretty sure what you're trying to do can't be
done -- that small "window" can't be moved to a different part of the
display. And if I'm wrong, well, it won't be the first time, but maybe I
won't get flamed for it this time. :-D
Charlie
ck@...
----- Original Message -----
From: "Mert Börü" <mert@...>
To: <gbadev@yahoogroups.com>
Sent: Friday, August 31, 2001 10:38 AM
Subject: Re: [gbadev] BG0-3 SCX, SCY
> Thanks for your fast reply...
> But, I am afraid no scroll happens. Is it because that I am using MODE 5?
>
> By the way, what I am trying to do is, to centralize the MODE 5 gfx,
instead of
> leaving it at the topleft corner. I thought it was possible with the
x/yoffset
> for background registers (0x4000010-0x400001E). Possible?
>
> Kind Regards,
> Mert
>
> "Dickinson, Vince" wrote:
>
> > I believe 0x4000010 is the xoffset for background 0, and x1E is the
yoffset
> > for background 3. Make sure you have the correct background enabled.
(BTW,
> > x12 is bkgd 0's y, and x1c is bkgd 3's x). You should just be able to
set
> > them to the scroll value as in:
> >
> > *( vu16 *)0x4000010 = xoffset; // bkgd 0 x
> > *( vu16 *)0x4000012 = yoffset; // bkgd 0 y
> >
> > -V
> >
> > -----Original Message-----
> > From: Mert Börü [mailto:mert@...]
> > Sent: Friday, August 31, 2001 8:54 AM
> > To: GBAdev
> > Subject: [gbadev] BG0-3 SCX, SCY
> >
> > Would anyone like to explain the practical usage of registers 0x4000010
> > to 0x400001E?
> >
> > ps: According to AgentQ's GameBoy Advance Internals doc, "these
> > registers set the pixel that is displayed in the top left hand corner of
> > the GBA's display. All four BG planes wrap when they reach their right
> > or bottom edges, as they do on the standard Gameboy".
> >
> > F E D C B A 9 8 7 6 5 4 3 2 1 0
> > X X X X X X S S S S S S S S S S
> >
> > S = Scroll value (pixels)
> >
> > ... But, NOTHING happens/changes when I change the status of these bits
> > in the related register. Am I missing something???
> >
> > Kind Regards,
> > --
> > Mert Börü
> > Digital Media Development
> >
> > info(+)TRON A.Ş.
> > "Birlikte Geleceği Yaratıyoruz"
> >
> > Prof. Dr. F. K. Gökay Cad. No:27/3
> > Altunizade 81190 Istanbul
> > TURKEY
> >
> > Tel: +90-216-492-1002 e-mail:mert@...
> > Fax: +90-216-343-2132 http://www.infotron.com.tr
> >
> > 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/
> >
> >
> > 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/
>
>
>
> 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/
>
>
On Fri, 31 Aug 2001, Mert [iso-8859-9] Börü wrote:
> Thanks for your fast reply...
> But, I am afraid no scroll happens. Is it because that I am using MODE 5?
Mode 5 can be scale/rotated/scrolled using the BG2 scaling/rotate/scolling
registers.
> for background registers (0x4000010-0x400001E). Possible?
>
> Kind Regards,
> Mert
>
> "Dickinson, Vince" wrote:
>
> > I believe 0x4000010 is the xoffset for background 0, and x1E is the yoffset
> > for background 3. Make sure you have the correct background enabled. (BTW,
> > x12 is bkgd 0's y, and x1c is bkgd 3's x). You should just be able to set
> > them to the scroll value as in:
> >
> > *( vu16 *)0x4000010 = xoffset; // bkgd 0 x
> > *( vu16 *)0x4000012 = yoffset; // bkgd 0 y
> >
> > -V
> >
> > -----Original Message-----
> > From: Mert Börü [mailto:mert@...]
> > Sent: Friday, August 31, 2001 8:54 AM
> > To: GBAdev
> > Subject: [gbadev] BG0-3 SCX, SCY
> >
> > Would anyone like to explain the practical usage of registers 0x4000010
> > to 0x400001E?
> >
> > ps: According to AgentQ's GameBoy Advance Internals doc, "these
> > registers set the pixel that is displayed in the top left hand corner of
> > the GBA's display. All four BG planes wrap when they reach their right
> > or bottom edges, as they do on the standard Gameboy".
> >
> > F E D C B A 9 8 7 6 5 4 3 2 1 0
> > X X X X X X S S S S S S S S S S
> >
> > S = Scroll value (pixels)
> >
> > ... But, NOTHING happens/changes when I change the status of these bits
> > in the related register. Am I missing something???
> >
> > Kind Regards,
> > --
> > Mert Börü
> > Digital Media Development
> >
> > info(+)TRON A.Ş.
> > "Birlikte Geleceği Yaratıyoruz"
> >
> > Prof. Dr. F. K. Gökay Cad. No:27/3
> > Altunizade 81190 Istanbul
> > TURKEY
> >
> > Tel: +90-216-492-1002 e-mail:mert@...
> > Fax: +90-216-343-2132 http://www.infotron.com.tr
> >
> > 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/
> >
> >
> > 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/
>
>
>
> 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/
>
>
--
The Phoenix -- The Artistic Intuition Company
Runica * Phoenix Quake * Caelius * Zen-X * Mirror Reflex * Infinite Realms
Eeeek mode 5 :) I haven't done anything with that, but you have to enable
BG2. I believe you have to scroll with the scaling/rot. params BG2X, BGY.
BG2HOFS and BG2YOFS may be ignored in mode 5.
(vs32 *)0x4000028 = (xoffset<<8); // shift 8 to fit fixed point
format
(vs32 *)0x400002c = (yffset<<8);
or something like that.
Sorry in advance for replying without testing, but I'm *pretty* sure this is
accurate info :)
-V
-----Original Message-----
From: Mert Börü [mailto:mert@...]
Sent: Friday, August 31, 2001 10:38 AM
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] BG0-3 SCX, SCY
Thanks for your fast reply...
But, I am afraid no scroll happens. Is it because that I am using MODE 5?
By the way, what I am trying to do is, to centralize the MODE 5 gfx, instead
of
leaving it at the topleft corner. I thought it was possible with the
x/yoffset
for background registers (0x4000010-0x400001E). Possible?
Kind Regards,
Mert
"Dickinson, Vince" wrote:
> I believe 0x4000010 is the xoffset for background 0, and x1E is the
yoffset
> for background 3. Make sure you have the correct background enabled.
(BTW,
> x12 is bkgd 0's y, and x1c is bkgd 3's x). You should just be able to set
> them to the scroll value as in:
>
> *( vu16 *)0x4000010 = xoffset; // bkgd 0 x
> *( vu16 *)0x4000012 = yoffset; // bkgd 0 y
>
> -V
>
> -----Original Message-----
> From: Mert Börü [mailto:mert@...]
> Sent: Friday, August 31, 2001 8:54 AM
> To: GBAdev
> Subject: [gbadev] BG0-3 SCX, SCY
>
> Would anyone like to explain the practical usage of registers 0x4000010
> to 0x400001E?
>
> ps: According to AgentQ's GameBoy Advance Internals doc, "these
> registers set the pixel that is displayed in the top left hand corner of
> the GBA's display. All four BG planes wrap when they reach their right
> or bottom edges, as they do on the standard Gameboy".
>
> F E D C B A 9 8 7 6 5 4 3 2 1 0
> X X X X X X S S S S S S S S S S
>
> S = Scroll value (pixels)
>
> ... But, NOTHING happens/changes when I change the status of these bits
> in the related register. Am I missing something???
>
> Kind Regards,
> --
> Mert Börü
> Digital Media Development
>
> info(+)TRON A.Ş.
> "Birlikte Geleceği Yaratıyoruz"
>
> Prof. Dr. F. K. Gökay Cad. No:27/3
> Altunizade 81190 Istanbul
> TURKEY
>
> Tel: +90-216-492-1002 e-mail:mert@...
> Fax: +90-216-343-2132 http://www.infotron.com.tr
>
> 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/
>
>
> 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/
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/
Thanks for your fast reply...
But, I am afraid no scroll happens. Is it because that I am using MODE 5?
By the way, what I am trying to do is, to centralize the MODE 5 gfx, instead of
leaving it at the topleft corner. I thought it was possible with the x/yoffset
for background registers (0x4000010-0x400001E). Possible?
Kind Regards,
Mert
"Dickinson, Vince" wrote:
> I believe 0x4000010 is the xoffset for background 0, and x1E is the yoffset
> for background 3. Make sure you have the correct background enabled. (BTW,
> x12 is bkgd 0's y, and x1c is bkgd 3's x). You should just be able to set
> them to the scroll value as in:
>
> *( vu16 *)0x4000010 = xoffset; // bkgd 0 x
> *( vu16 *)0x4000012 = yoffset; // bkgd 0 y
>
> -V
>
> -----Original Message-----
> From: Mert Börü [mailto:mert@...]
> Sent: Friday, August 31, 2001 8:54 AM
> To: GBAdev
> Subject: [gbadev] BG0-3 SCX, SCY
>
> Would anyone like to explain the practical usage of registers 0x4000010
> to 0x400001E?
>
> ps: According to AgentQ's GameBoy Advance Internals doc, "these
> registers set the pixel that is displayed in the top left hand corner of
> the GBA's display. All four BG planes wrap when they reach their right
> or bottom edges, as they do on the standard Gameboy".
>
> F E D C B A 9 8 7 6 5 4 3 2 1 0
> X X X X X X S S S S S S S S S S
>
> S = Scroll value (pixels)
>
> ... But, NOTHING happens/changes when I change the status of these bits
> in the related register. Am I missing something???
>
> Kind Regards,
> --
> Mert Börü
> Digital Media Development
>
> info(+)TRON A.Ş.
> "Birlikte Geleceği Yaratıyoruz"
>
> Prof. Dr. F. K. Gökay Cad. No:27/3
> Altunizade 81190 Istanbul
> TURKEY
>
> Tel: +90-216-492-1002 e-mail:mert@...
> Fax: +90-216-343-2132 http://www.infotron.com.tr
>
> 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/
>
>
> 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/
Also, those reg's are ignored if you're doing scaling/rotation on the bkgd
in mode 1/2.
-V
-----Original Message-----
From: Mert Börü [mailto:mert@...]
Sent: Friday, August 31, 2001 8:54 AM
To: GBAdev
Subject: [gbadev] BG0-3 SCX, SCY
Would anyone like to explain the practical usage of registers 0x4000010
to 0x400001E?
ps: According to AgentQ's GameBoy Advance Internals doc, "these
registers set the pixel that is displayed in the top left hand corner of
the GBA's display. All four BG planes wrap when they reach their right
or bottom edges, as they do on the standard Gameboy".
F E D C B A 9 8 7 6 5 4 3 2 1 0
X X X X X X S S S S S S S S S S
S = Scroll value (pixels)
... But, NOTHING happens/changes when I change the status of these bits
in the related register. Am I missing something???
Kind Regards,
--
Mert Börü
Digital Media Development
info(+)TRON A.Ş.
"Birlikte Geleceği Yaratıyoruz"
Prof. Dr. F. K. Gökay Cad. No:27/3
Altunizade 81190 Istanbul
TURKEY
Tel: +90-216-492-1002 e-mail:mert@...
Fax: +90-216-343-2132 http://www.infotron.com.tr
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/
> the results I expect. If I only set it once, outside a loop, then the
> address gets corrupted and following DMA's fail.
> Has anyone had any experience with this? Can anyone say how the hardware
> handles this?
Are You sure that You are setting registers in right moment ?
On GBA You can't change any DMA register while DMA is in
progress.
--
Adam Bienias
Metropolis Software Programmer
mailto:nauplay@...
mailto:adam@...
-------------------- [POLBOX - REKLAMA] ------------------------
SprawdŸ swoje bezpieczeñstwo w Sieci
Zabezpiecz siê ! www.symantec.com/region/pl/product/nis2001.html
----------------------------------------------------------------
> Has anyone had any experience with this? Can anyone say how the hardware
> handles this?
Hardware keeps the original addresses given. I.e. you can restart the DMA
and it will transfer the same data again.
--Jim
I believe 0x4000010 is the xoffset for background 0, and x1E is the yoffset
for background 3. Make sure you have the correct background enabled. (BTW,
x12 is bkgd 0's y, and x1c is bkgd 3's x). You should just be able to set
them to the scroll value as in:
*( vu16 *)0x4000010 = xoffset; // bkgd 0 x
*( vu16 *)0x4000012 = yoffset; // bkgd 0 y
-V
-----Original Message-----
From: Mert Börü [mailto:mert@...]
Sent: Friday, August 31, 2001 8:54 AM
To: GBAdev
Subject: [gbadev] BG0-3 SCX, SCY
Would anyone like to explain the practical usage of registers 0x4000010
to 0x400001E?
ps: According to AgentQ's GameBoy Advance Internals doc, "these
registers set the pixel that is displayed in the top left hand corner of
the GBA's display. All four BG planes wrap when they reach their right
or bottom edges, as they do on the standard Gameboy".
F E D C B A 9 8 7 6 5 4 3 2 1 0
X X X X X X S S S S S S S S S S
S = Scroll value (pixels)
... But, NOTHING happens/changes when I change the status of these bits
in the related register. Am I missing something???
Kind Regards,
--
Mert Börü
Digital Media Development
info(+)TRON A.Ş.
"Birlikte Geleceği Yaratıyoruz"
Prof. Dr. F. K. Gökay Cad. No:27/3
Altunizade 81190 Istanbul
TURKEY
Tel: +90-216-492-1002 e-mail:mert@...
Fax: +90-216-343-2132 http://www.infotron.com.tr
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/
I've been playing around with DMA3. It seems like MappyVM resets or
corrupts the "Source Address Register" for DMA3 after each transfer. I
found that if I set the register to my source address inside a loop, I get
the results I expect. If I only set it once, outside a loop, then the
address gets corrupted and following DMA's fail.
It doesn't seem like Boycott Advance does the same thing. I can set the DMA
source address just once here and each DMA copies from the correct address.
Has anyone had any experience with this? Can anyone say how the hardware
handles this?
thanks,
-- John
-----Original Message-----
From: Mert Börü [mailto:mert@...]
Sent: Friday, August 31, 2001 9:54 AM
To: GBAdev
Subject: [gbadev] BG0-3 SCX, SCY
Would anyone like to explain the practical usage of registers 0x4000010
to 0x400001E?
ps: According to AgentQ's GameBoy Advance Internals doc, "these
registers set the pixel that is displayed in the top left hand corner of
the GBA's display. All four BG planes wrap when they reach their right
or bottom edges, as they do on the standard Gameboy".
F E D C B A 9 8 7 6 5 4 3 2 1 0
X X X X X X S S S S S S S S S S
S = Scroll value (pixels)
... But, NOTHING happens/changes when I change the status of these bits
in the related register. Am I missing something???
Kind Regards,
--
Mert Börü
Digital Media Development
info(+)TRON A.S.
"Birlikte Gelecegi Yaratiyoruz"
Prof. Dr. F. K. Gökay Cad. No:27/3
Altunizade 81190 Istanbul
TURKEY
Tel: +90-216-492-1002 e-mail:mert@...
Fax: +90-216-343-2132 http://www.infotron.com.tr
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/
Would anyone like to explain the practical usage of registers 0x4000010
to 0x400001E?
ps: According to AgentQ's GameBoy Advance Internals doc, "these
registers set the pixel that is displayed in the top left hand corner of
the GBA's display. All four BG planes wrap when they reach their right
or bottom edges, as they do on the standard Gameboy".
F E D C B A 9 8 7 6 5 4 3 2 1 0
X X X X X X S S S S S S S S S S
S = Scroll value (pixels)
... But, NOTHING happens/changes when I change the status of these bits
in the related register. Am I missing something???
Kind Regards,
--
Mert Börü
Digital Media Development
info(+)TRON A.Ş.
"Birlikte Geleceği Yaratıyoruz"
Prof. Dr. F. K. Gökay Cad. No:27/3
Altunizade 81190 Istanbul
TURKEY
Tel: +90-216-492-1002 e-mail:mert@...
Fax: +90-216-343-2132 http://www.infotron.com.tr
@objcopy -v -O binary ???.elf ???.bin
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
> I bet you can buy some surplus plastic casings from Bung or somebody
> else (just write all these guys in HK making pirate GBC carts) and
> thus save all the hassle and overtime in using your own injection
> facilities.
I dont know who these people are. That is a good Idea to ask them!
>
> I reckon that -if it takes 10 min. to make one single cart- it's too
> much time and you have to add that up to the final cost... I have
> never done anything like that, but I wager you can get some cheap
> cases the other way.
>
> Besides, I think this whole idea is pretty cool. There's one last
> thing I don't really grasp: are you going to burn the chips on demand
> or you're planning to sell the stuff to other people to write'em...
My first plan is to put the rom into a socket. If a person want to do a lot
they will have to buy a programmer. If on the other hand they only want one
to, oh say, 10; then I could do it.
> I mean, you can still make some extra cash by burning them on demand
> to demoers, etc., that wish to show off their stuff to publishers and
> what not.
Thats what Im thinking.
>If you sell the carts for others to burn I don't think it's
> going to work out. That's just an opinion, but I'd rather send you a
> zipped file with the contents along with some cash so you can write,
> say, 15 or 20 carts and then send them back to me so I can impress
> all my pals! :-)
20 per person might be pushing it. Unless it proves that I can pay the
bills with it..
Hi Vince!
DV> I'm having a bit of a problem moving code to internal ram. My little ARM
DV> assembler routine that inc's a specific variable is as follows:
when you write
DV> ldr r2, =xoffset @ variable is located in
the address of your variable is stored in literal pool and will be
accessed through
ldr r2,[pc,#offset]
When you move your code to ram, the offset still points to literal pool
which you didn't copied with your code.
ldr r2,=xoffset
...
.pool (or .LTPOOL if you use ARMASM)
I wrote a program to flip the interwork bit on object files. Its purpose
is to flip the interworking bits on object files you create from binary
data files. Object from binary files don't have the bit set, so if you
link them with a project that uses interworking then you will get
warnings. These warnings are harmless, but annoying. So, I banged out
this program to quickly fix that.
Usage: interflip {-mthumb-interwork|-mno-thumb-interwork} file(s)
Example:
interflip -mthumb-interwork music0.o
will set the interwork flag on music0.o
interflip -mno-thumb-interwork music*.o will remove it from all your music
files.
here is the source and exe for win32 cygwin:
http://www.io.com/~fenix/devkitadv/interflip.zip
Just put it in the bin directory of DevKit Advance or whatever gcc you are
using.
If anyone is absolutely loaded and fancies buying me a pint, I'll be
around at ECTS Sunday afternoon avoiding any tech talk of any
sort!
Alex Amsel (#irc sillytuna)
Tuna Technologies Ltd (Sheffield)
Nintendo Gameboy Advance Specialists
Tel: +44 (0)114 266 2211 Mob: +44(0)7771 524 632
I would like to know if anyone noticed if builds are slower since I fixed
the problem in Win9x. The memory management concerns me, I'm afraid it
may be slower. But if no one has noticed then I won't worry about it.
> I plan to make a write once cart soon. The memory for 4 Mega BYTES
not bits
[...]
Hi, Daniel!
I bet you can buy some surplus plastic casings from Bung or somebody
else (just write all these guys in HK making pirate GBC carts) and
thus save all the hassle and overtime in using your own injection
facilities.
I reckon that -if it takes 10 min. to make one single cart- it's too
much time and you have to add that up to the final cost... I have
never done anything like that, but I wager you can get some cheap
cases the other way.
Besides, I think this whole idea is pretty cool. There's one last
thing I don't really grasp: are you going to burn the chips on demand
or you're planning to sell the stuff to other people to write'em...
I mean, you can still make some extra cash by burning them on demand
to demoers, etc., that wish to show off their stuff to publishers and
what not. If you sell the carts for others to burn I don't think it's
going to work out. That's just an opinion, but I'd rather send you a
zipped file with the contents along with some cash so you can write,
say, 15 or 20 carts and then send them back to me so I can impress
all my pals! :-)
Just my 2 pesetas.
David Brioso
Hello Jason,
Thursday, August 30, 2001, 7:05:00 PM, you wrote:
JW> On Thu, 30 Aug 2001, Dickinson, Vince wrote:
>> 080001C4 E59F2020 LDR r2 , $080001EC <- Address of
the
>> variable I want to inc?
JW> How can you increment a variable in ROM?
screwdriver?
:o)
--
Best regards,
groepaz mailto:groepaz@...
I can't help you with any books, but you can pick a lot up from reading this
list!
-----Original Message-----
From: Dickinson, Vince [mailto:vinced@...]
Sent: 30 August 2001 17:37
To: 'gbadev@yahoogroups.com'
Subject: RE: [gbadev] absolute/relative addresses of code in ram
Thanks Tom,
Ahhhh, that's good. I didn't understand that the assembler kept arbitrary
addresses (like the address of my variable) in a table after the function.
I copied ONLY my function to ram, not the data immediately following it.
Now it seems to work! BTW, can you recommend any books or references for
this type of thing. I've been pouring over the gnu asm manuals and a couple
of informal things on the web but they only cover the opcodes, not really
the operation of the assembler itself.
Thanks 10^6,
Vince
[Non-text portions of this message have been removed]
On Thu, 30 Aug 2001, Dickinson, Vince wrote:
> 080001C4 E59F2020 LDR r2 , $080001EC <- Address of the
> variable I want to inc?
How can you increment a variable in ROM?