I had this same problem i dont know what it is ether!! is it Bimbo?

I'm using it for an high precision non real-time 3d renderer.

Mat


----- Original Message -----
From: Evan Robinson <erobinson@...>
To: <gbadev@yahoogroups.com>
Sent: Monday, April 01, 2002 2:01 AM
Subject: Re: [gbadev] Floating point speed?


> I'd suggest that you encapsulate your math data types so that you can
> go either way.  But at this point, I bet the 64bit fixed point will
> be substantially faster.
>
> What are you planning to use them for?
>
> Evan
>
> At 12:28 AM +0100 on 2002.04.01, Mat wrote about "Re: [gbadev]
> Floating point speed?":
> >Hi Evan
> >
> >I know that the ARM7TDMI does not support fp instructions. I am just
> >wondering if anyone had done any experimentation; I was trying to save
> >myself the time of doing the tests. Although looking at the assem output
> >today of some 64-bit math code it is pretty minimal so I may be using
64-bit
> >fixed point instead.
> >
> >Thanks
> >
> >Mat

[cropped by mod]

Hi,

I bet that most application on the GBA should be satisfied with a 32 Bit
fixed point calculation.
It is just a matter of trade off for the precision you need on the integer
part and floating part.

Personnally I can not see any application which requires the precision of a
float on this platform.
(whatever it is... position of a unit in the game, 3D/2D computation).

Thats not because you want to use values that have more precision than a
simple integer that you need to use
a float right away...

You should have a look to the documents on the ARM Web site...
One of the document is about using fixed point calculation with a ARM CPU.

64 Bit calculation will use twice of your register and greatly impact your
speed.
And still I am not sure about the fact that you need 64 Bit to store your
information.

Romain.

----- Original Message -----
From: "Evan Robinson" <erobinson@...>
To: <gbadev@yahoogroups.com>
Sent: Monday, April 01, 2002 10:01 AM
Subject: Re: [gbadev] Floating point speed?


> I'd suggest that you encapsulate your math data types so that you can
> go either way.  But at this point, I bet the 64bit fixed point will
> be substantially faster.
>
> What are you planning to use them for?
>
> Evan
>
> At 12:28 AM +0100 on 2002.04.01, Mat wrote about "Re: [gbadev]
> Floating point speed?":
> >Hi Evan
> >
> >I know that the ARM7TDMI does not support fp instructions. I am just
> >wondering if anyone had done any experimentation; I was trying to save
> >myself the time of doing the tests. Although looking at the assem output
> >today of some 64-bit math code it is pretty minimal so I may be using
64-bit
> >fixed point instead.
> >
> >Thanks
> >
> >Mat
> >
> >

>Yeah, I think what it's doing is trying to store the picture in Ram, which
>is too small to hold it all.

Oh, duh, I should have known that.  Works fine, now =)




Stupid like a fox!
Look ma, I'm an artist: http://aaronstj.deviantart.com


_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com

I'd suggest that you encapsulate your math data types so that you can
go either way.  But at this point, I bet the 64bit fixed point will
be substantially faster.

What are you planning to use them for?

	 Evan

At 12:28 AM +0100 on 2002.04.01, Mat wrote about "Re: [gbadev]
Floating point speed?":
>Hi Evan
>
>I know that the ARM7TDMI does not support fp instructions. I am just
>wondering if anyone had done any experimentation; I was trying to save
>myself the time of doing the tests. Although looking at the assem output
>today of some 64-bit math code it is pretty minimal so I may be using 64-bit
>fixed point instead.
>
>Thanks
>
>Mat
>
>
>----- Original Message -----
>From: Evan Robinson <erobinson@...>
>To: <gbadev@yahoogroups.com>
>Sent: Sunday, March 31, 2002 10:47 PM
>Subject: Re: [gbadev] Floating point speed?
>
>
>>  YMMV:  I'm a newbie at the ARM.
>>
>>  I don't see floating point math in the ARM instruction set, so doing
>>  true floating point is going to depend on the library you are using
>>  -- in other words, you need to test it.  But it will be slower than
>>  integer math.
>>
>>  If you're talking about fixed point (integer math with a decimal
>>  point, essentially), add and subtract are just as fast as integer,
>>  multiply requires an additional shift of N places where N is twice
>>  your number of decimal points.  I don't remember about division.
>>
>>  The short answer, if it's all you need, is that floating point is
>>  slow compared to integers.
>>
>>  Evan
>>
>>  At 9:04 PM +0000 on 2002.03.30, Mat wrote about "Re: [gbadev]
>>  Floating point speed?":
>>  >OK, CPU cycles may be a bit too much so what about in comparison to their
>>  >integer equivalents?
>>  >
>>  >Thanks
>>  >
>>  >Mat
>>  >
>>  >
>>  >
>>  >----- Original Message -----
>>  >From: Mat <matth@...>
>>  >To: <gbadev@yahoogroups.com>
>>  >Sent: Saturday, March 30, 2002 3:12 AM
>>  >Subject: [gbadev] Floating point speed?
>>  >
>>  >
>>  >>  Hi
>>  >>
>>  >>  Does anyone have any approximate floating point calculation speeds for
>>  >>  operators such as +, * and / in cpu cycles?
>>  >>
>>  >>  Thanks
>>  >>
>>  >>  Mat
>
>[cropped by mod]
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



It's hard to write foolproof software because there are so many fools,
and they are very inventive.

Hi

> Hi guys.  Just got into GBADev (you may remember me from the GBCDev
scene),
> and I'm running into a problem with simple mode 3 stuff.  I'm trying to
have
> a program that just displays a bitmap, but all I'm getting is the bottom
> third or so of my bitmap repeated about three times, with some garbage
> pixels in between.  I used Bimbo to do the bmp->gba conversion, exporting
as
> an array of unisgned short ints.

Yeah, I think what it's doing is trying to store the picture in Ram, which
is too small to hold it all.

what you should do is define the array that holds the picture like so:

"const unsigned short int name[xxx] = { data }"

by making it a constant the compile will leave the array in ROM, so when you
access the data you can fetch it all from rom rather then it trying to get
it from ram


Andrew

Hi guys.  Just got into GBADev (you may remember me from the GBCDev scene),
and I'm running into a problem with simple mode 3 stuff.  I'm trying to have
a program that just displays a bitmap, but all I'm getting is the bottom
third or so of my bitmap repeated about three times, with some garbage
pixels in between.  I used Bimbo to do the bmp->gba conversion, exporting as
an array of unisgned short ints.  I'm compiling with DevKitAdvanced.  This
is the code I'm using:

int main()
{
	 int x, y, index;

	 u16* ScreenBuffer = (u16*)0x6000000;

	 REG_DISPCNT = MODE3 | BG2_ENABLE;

	 for(index = 0; index < 240*160; index++)
		 ScreenBuffer[index] = gbarogueBitmap[index];
}

Anyone know what the problem is?  Seems very odd to me.




Stupid like a fox!
Look ma, I'm an artist: http://aaronstj.deviantart.com


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx

Hi Evan

I know that the ARM7TDMI does not support fp instructions. I am just
wondering if anyone had done any experimentation; I was trying to save
myself the time of doing the tests. Although looking at the assem output
today of some 64-bit math code it is pretty minimal so I may be using 64-bit
fixed point instead.

Thanks

Mat


----- Original Message -----
From: Evan Robinson <erobinson@...>
To: <gbadev@yahoogroups.com>
Sent: Sunday, March 31, 2002 10:47 PM
Subject: Re: [gbadev] Floating point speed?


> YMMV:  I'm a newbie at the ARM.
>
> I don't see floating point math in the ARM instruction set, so doing
> true floating point is going to depend on the library you are using
> -- in other words, you need to test it.  But it will be slower than
> integer math.
>
> If you're talking about fixed point (integer math with a decimal
> point, essentially), add and subtract are just as fast as integer,
> multiply requires an additional shift of N places where N is twice
> your number of decimal points.  I don't remember about division.
>
> The short answer, if it's all you need, is that floating point is
> slow compared to integers.
>
> Evan
>
> At 9:04 PM +0000 on 2002.03.30, Mat wrote about "Re: [gbadev]
> Floating point speed?":
> >OK, CPU cycles may be a bit too much so what about in comparison to their
> >integer equivalents?
> >
> >Thanks
> >
> >Mat
> >
> >
> >
> >----- Original Message -----
> >From: Mat <matth@...>
> >To: <gbadev@yahoogroups.com>
> >Sent: Saturday, March 30, 2002 3:12 AM
> >Subject: [gbadev] Floating point speed?
> >
> >
> >>  Hi
> >>
> >>  Does anyone have any approximate floating point calculation speeds for
> >>  operators such as +, * and / in cpu cycles?
> >>
> >>  Thanks
> >>
> >>  Mat

[cropped by mod]

YMMV:  I'm a newbie at the ARM.

I don't see floating point math in the ARM instruction set, so doing
true floating point is going to depend on the library you are using
-- in other words, you need to test it.  But it will be slower than
integer math.

If you're talking about fixed point (integer math with a decimal
point, essentially), add and subtract are just as fast as integer,
multiply requires an additional shift of N places where N is twice
your number of decimal points.  I don't remember about division.

The short answer, if it's all you need, is that floating point is
slow compared to integers.

	 Evan

At 9:04 PM +0000 on 2002.03.30, Mat wrote about "Re: [gbadev]
Floating point speed?":
>OK, CPU cycles may be a bit too much so what about in comparison to their
>integer equivalents?
>
>Thanks
>
>Mat
>
>
>
>----- Original Message -----
>From: Mat <matth@...>
>To: <gbadev@yahoogroups.com>
>Sent: Saturday, March 30, 2002 3:12 AM
>Subject: [gbadev] Floating point speed?
>
>
>>  Hi
>>
>>  Does anyone have any approximate floating point calculation speeds for
>>  operators such as +, * and / in cpu cycles?
>>
>>  Thanks
>>
>>  Mat
>>
>>
>>
>>
>>
>>
>>
>>  Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>>
>>
>
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



Patriotism means to stand by the country. It does not mean to stand
by the president or any other public official, save exactly to the
degree in which he himself stands by the country. It is patriotic
to support him insofar as he efficiently serves the country. It is
unpatriotic not to oppose him to the exact extent that by inefficiency
or otherwise he fails in his duty to stand by the country. In either
event, it is unpatriotic not to tell the truth, whether about the
president or anyone else.
   -- Theodore Roosevelt

To all intents and purposes, mode 3 is THE SAME as mode 4.  Mode 4 has 2
byte per pixel buffers and mode 3 has a single word per pixel buffer.
There SHOULD be no difference in sprite code between the 2 modes, and
normally sprite characters should start at 512.

If you're getting corrupt graphics it's likely to be one of 2 things.
Either you're attempting to load sprites to character address 0 and then
overwriting it with the screen, or uploading to the correct place but
displaying sprites referencing from sprite character 0.

FGL

-----Original Message-----
From: Cesar Cappellozza [mailto:cappeca@...]
Sent: 31 March 2002 07:30
To: gbadev@yahoogroups.com
Subject: Re: Fw: [gbadev] Sprite in mode 4

But the example I was refering to was about mode 3,
which doesn't work. Could someone please point me what
is wrong, and which example is the best to follow
using modes 3 or 4?

Thanks in advance,

Cesar.


  --- Jim Bagley <jimbagley@...> escreveu: >
when in mode 4, the sprites start from 512 upwards,
> as the first 0x4000 bytes of sprite vram are used by
> the bottom of the second screen buffer.
>
> "and my sprite appears all weird, filling hole lines
> on
> the screen. I thought I was doing something wrong,"





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

Check out my site at proger.netfirms.com it has examples with sprites and
background layers, text and some other stuff. I havent been able to update
but i should soon.

But the example I was refering to was about mode 3,
which doesn't work. Could someone please point me what
is wrong, and which example is the best to follow
using modes 3 or 4?

Thanks in advance,

Cesar.


  --- Jim Bagley <jimbagley@...> escreveu: >
when in mode 4, the sprites start from 512 upwards,
> as the first 0x4000 bytes of sprite vram are used by
> the bottom of the second screen buffer.
>
> "and my sprite appears all weird, filling hole lines
> on
> the screen. I thought I was doing something wrong,"

Slightly OT this question, but I'm gonna ask anyway :)  Has anyone
actually taken advantage of the extra 160 16 colour characters available
and butted their sprite data slap bang at the end of the screen?

Well, from my calculations it's something like 160 characters anyway.
Screens end at 0x12c00 and sprites are SUPPOSED to start at 0x14000 in
mode 3 or 4.

FGL

-----Original Message-----
From: Jim Bagley [mailto:jimbagley@...]
Sent: 30 March 2002 21:11
To: gbadev@yahoogroups.com
Subject: Fw: [gbadev] Sprite in mode 4

when in mode 4, the sprites start from 512 upwards, as the first 0x4000
bytes of sprite vram are used by the bottom of the second screen buffer.

"and my sprite appears all weird, filling hole lines on
the screen. I thought I was doing something wrong,"





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

OK, CPU cycles may be a bit too much so what about in comparison to their
integer equivalents?

Thanks

Mat



----- Original Message -----
From: Mat <matth@...>
To: <gbadev@yahoogroups.com>
Sent: Saturday, March 30, 2002 3:12 AM
Subject: [gbadev] Floating point speed?


> Hi
>
> Does anyone have any approximate floating point calculation speeds for
> operators such as +, * and / in cpu cycles?
>
> Thanks
>
> Mat
>
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

when in mode 4, the sprites start from 512 upwards, as the first 0x4000 bytes of
sprite vram are used by the bottom of the second screen buffer.

"and my sprite appears all weird, filling hole lines on
the screen. I thought I was doing something wrong,"

At 1:14 AM +0000 on 2002.03.30, cappeca wrote about "[gbadev] Re:
Assembler syntax in DevKit programs":
>I'm trying that, and it gives me the message:
>    warning: multi-line string literals are deprecated
>
>Any way to fix this?
>
>Thanks,
>
>Cesar.
>
>--- In gbadev@y..., kulesa@n... wrote:
>>  Here is what I've used and it works on the emulators (I haven't
>tried
>>  it on real hardware though):
>>

The open quote on the line below this one

>  > asm("
>>  ldr r0, =0x4000006
>>  scanline_wait:
>>  ldrh r1, [r0]
>>  cmp r1, #160
>>  bne scanline_wait
>>         ":::"r0","r1"
>  >         )

creates a multi-line string literal when matched with the first quote
on the second to last line.  Apparently your compiler doesn't like it.

	 Evan


New company policy: You cannot work at a job that is rated higher
than your current competency level. You cannot be rated at a higher
competency level until you have worked at a job rated at that level.
You can not improve your competency level through training.
   -- http://www.myboss.com/

At 12:57 AM +0000 on 2002.03.30, treyjazz2k2 wrote about "[gbadev]
encoding/decoding assembly instructions <->hex":
>Does someone have the documentation of how the instructions are
>encoded/decoded to/from hex code? Thanks in advance for any help you
>can offer :)

Section 1.4.1 of the ARM Manual on the ARM7 describes the byte coding
of all instructions.  It's available free as a PDF on the ARM site
<http://www.arm.com> under Technical Reference Manuals (TRMs).

	 Evan


Today's Oxymoron:
   Soft rock

How do I put a sprite in mode 4 (mode 3 will help
too anyway). I have tried this tutorial:

http://216.167.73.47/~dovoto/English/tutorial_3.html

and my sprite appears all weird, filling hole lines on
the screen. I thought I was doing something wrong, so
I downloaded the demo on the site to check, and it
doesn't work either. What is wrong with it?

    What are the relations between modes and sprites? I
was also playing with the "sprite" demo, and once I
changed modes, it stopped working. What are the basics
to show a sprite? What is the best tutorial around?

Thanks,

Cesar

________________________________________________________________________________\
_______________
Yahoo! Empregos
O trabalho dos seus sonhos pode estar aqui. Cadastre-se hoje mesmo no Yahoo!
Empregos e tenha acesso a milhares de vagas abertas!
http://br.empregos.yahoo.com/

rEEjected has some good opcode sheets on his/her website:

	 http://www.agbdev.net/re-eject/

Erik

[mod: correct URL would be http://re-eject.gbadev.org/ ]

-----Original Message-----
From: treyjazz2k2 [mailto:comfortably_numb_@...]
Sent: Friday, March 29, 2002 7:58 PM
To: gbadev@yahoogroups.com
Subject: [gbadev] encoding/decoding assembly instructions <->hex code


Does someone have the documentation of how the instructions are
encoded/decoded to/from hex code? Thanks in advance for any help you
can offer :)

you should declare ScanlineCounter a vu16* (volatile).

> ok, i'm now calling the following code from a drawing loop to try to
> get some pausing time:
>
> void WaitForVblank(void){
> u16* ScanlineCounter;
> ScanlineCounter = (volatile u16*)0x4000006; //this is the
> scan line counter
> while(*ScanlineCounter < 160){ PrintNumber
> (*ScanlineCounter,0,0);}
>
> }
>
> the PrintNumber function is there for debug purposes, but it is never
> showing me the scanline number. i have to assume that it's not
> getting called. if i call this function 10 or 100000 times, i still
> don't get any pause. let me know what you think.
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

> Does someone have the documentation of how the instructions are
> encoded/decoded to/from hex code? Thanks in advance for any help you
> can offer :)

Look in the assembly section on Jeff's site: www.devrs.com/gba

Jan-Lieuwe

--- In gbadev@y..., "John Q. Pretentious" <johnisaheadcase@y...>
wrote:
> > I'm using the code from devoto's pern project (the Wait()
function)
> > to attain the proper speed for some animation in mode 4. I'm
making a
> > call to this function inside of a drawing loop. The problem is,
that
> > with different emulators, either all of the waiting is done before
> > the loops execute, or no waiting is done at all.
>
> Dovoto's wait() uses timers.  It seems like it would be quite a bit
simpler
> to use VSync.  Whereas timers ought to work, many emulators don't
get them
> right; I would be surprised if any of them got VSync wrong.
>
> Remember: KISS.  Otherwise, you'll end up with a monstrosity like
my current
> codebase, a fate I wouldn't wish on anyone.
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com

ok, i'm now calling the following code from a drawing loop to try to
get some pausing time:

void WaitForVblank(void){
	 u16* ScanlineCounter;
	 ScanlineCounter = (volatile u16*)0x4000006; //this is the
scan line counter
	 while(*ScanlineCounter < 160){ PrintNumber
(*ScanlineCounter,0,0);}

}

the PrintNumber function is there for debug purposes, but it is never
showing me the scanline number. i have to assume that it's not
getting called. if i call this function 10 or 100000 times, i still
don't get any pause. let me know what you think.

Hi

Does anyone have any approximate floating point calculation speeds for
operators such as +, * and / in cpu cycles?

Thanks

Mat

I'm trying that, and it gives me the message:
    warning: multi-line string literals are deprecated

Any way to fix this?

Thanks,

Cesar.

--- In gbadev@y..., kulesa@n... wrote:
> Here is what I've used and it works on the emulators (I haven't
tried
> it on real hardware though):
>
>  asm("
> 	 ldr  r0, =0x4000006
> 	 scanline_wait:
> 	 ldrh r1, [r0]
> 	 cmp r1, #160
> 	 bne  scanline_wait
> 	        ":::"r0","r1"
>         )
>
> --- In gbadev@y..., "Joseph Harvey" <mouldiwarp@h...> wrote:
> > I have just moved over to DevKit-Advance from ARM SDT.  What
> > is the syntax for including assembler statements?  I am using
> > Eloist's vertical sync function which looks like this:
> >
> > void vsync()
> > {
> >   __asm
> >    {
> >     mov  r0, #0x4000006   // load vertical trace counter into r0
> >     scanline_wait:               // lable
> >      ldrh r1, [r0]         // move r0 value into r1
> >      cmp r1, #160         // compare r1 with 160
> >     bne  scanline_wait    // if equal end else goto lable
> >    }
> > }
> >
> > And I get these errors when I try to compile:
> > In function 'vsync':
> > parse error before '{' token
> > syntax error at '#' token
> > invalid suffix on integer constant
> > syntax error at '#' token
> > I'm sorry if something similar has been asked before. Thanks.

Does someone have the documentation of how the instructions are
encoded/decoded to/from hex code? Thanks in advance for any help you
can offer :)

Where can i get this IceAge trailer for GBA?

   ----- Original Message -----
   From: fredrik averpil _
   To: gbadev@yahoogroups.com
   Sent: Monday, March 25, 2002 3:34 AM
   Subject: Re: [gbadev] AVI movies


   i have seen it too, and i am very curious about how they did that.

   /fredrik



   ----- Original Message -----
   From: "Barrett, Anthony" <anthony.barrett@...>
   To: <gbadev@yahoogroups.com>
   Sent: Saturday, March 23, 2002 10:10 AM
   Subject: [gbadev] AVI movies


   > Has anyone seen the IceAge GBA demo, what are they using there, because
   its
   > the trailer in full, but only takes up the size of a single rom.

It's a VERY good player, and the quality can be changed according to the
rom space you would give to your movie. There's a couple of movies of a
BMW trailer that show you the difference between a high quality movie
and a low quality one; you should look at them.

Droid


-----Messaggio originale-----
Da: Alex Ganea [mailto:alex_toresh@...]
Inviato: venerdì 29 marzo 2002 21.09
A: gbadev@yahoogroups.com
Oggetto: Re: [gbadev] AVI movies


How much is it do you know? From what I heard the quality is not that
good, anyone had experiences with thier player?

Alex.

[cropped by mod]

> I'm using the code from devoto's pern project (the Wait() function)
> to attain the proper speed for some animation in mode 4. I'm making a
> call to this function inside of a drawing loop. The problem is, that
> with different emulators, either all of the waiting is done before
> the loops execute, or no waiting is done at all.

Dovoto's wait() uses timers.  It seems like it would be quite a bit simpler
to use VSync.  Whereas timers ought to work, many emulators don't get them
right; I would be surprised if any of them got VSync wrong.

Remember: KISS.  Otherwise, you'll end up with a monstrosity like my current
codebase, a fate I wouldn't wish on anyone.


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

> Is it possible on GBA?
> Ifso, does anyone have a fast sourcecode for me to look at ? :-)

There has been a significant amount of list traffic on this issue.  Whereas
the question is still open, it should be noted that ARM engineers have
released source optimized for the ARM; my personal belief is that it is
possible, but very difficult.

If you search for previous traffic, you'll find quite a bit of material.


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

> > I know that actually the only Nintendo is in charge to
> > develop title on 16MB cardrige...
>
> Where are you guys getting this information??  Nintendo has
> 128Mbit flash carts for sale on their developer website!  Plus,
> I am just finishing a 128mbit game, and I am a third-party
> developer, so hopefully that answers any questions.  As of
> my knowledge, 128mbit is the biggest you can get right now,
> 256mbit will be released later on, but Nintendo won't tell us
> when.

Note that 16 MB = 128Mb.

The last time I checked, Big N only allowed themselves 16MB carts, and 8MB
to 3rd party developers.  However, that was a few months ago, and the person
who informed me of that said that it was due to change RSN.  That may have
already come to pass.  Regardless, they're not likely to allow 3rd party
developers to release 32MB apps for a while after they've allowed it to
themselves, if the person who told me this was accurate.  This is all second
hand and unverifiable, but it's from a reputable individual.




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