Hello Christophe,

PC> The only thing I regret, is that I don't know how you managed to get the
PC> official header files
PC> (unless you are official developpers) ;|

the web is your tool-use it ;=)

--
Best regards,
  groepaz                            mailto:groepaz@...

> Does anybody knows if turning the ROM prefetch system on consumes a
> significant amount of power ?

Not significantly. Something like a few minutes for a whole set of
batteries.

--Jim

Does anybody knows if turning the ROM prefetch system on consumes a
significant amount of power ?
Maybe this prefetch is enabled by default, I do not know.

(note: I would like to have to prefetch on)

Thanks

Hello Jason,

JW> I AM writing the "mother of all linker scripts," and I believe that all
JW> this linker script nonsense is silly, its like asking people to write
JW> their own assemblers and compilers.  I think that 99 percent of what
JW> people want to do can be moved to a much higher level without much or any
JW> lose of efficiency or control.  So 99 percent of people should never have
JW> to touch their linker scripts.

if you cant write a _simple_ thing like a linker script.... ehrm....
you better dont call yourself a coder. really.

JW> I might be wrong, but if I'm right everyone can stop complaining "my
JW> variables don't change" and "C++ doesn't work!" and "how do you copy
JW> functions into internal wram" and all that and just worry about writing
JW> game code.

how can people write other than crap games if they dont even know how
to setup their tools properly? strange world.

JW> On another note, When a person complains about putting const on stuff that
JW> IS const, I can't help but get the impression that they care more about
JW> how their code looks than how it works.

yes indeed ;=)


--
Best regards,
  groepaz                            mailto:groepaz@...

Thank you Tom, groepaz and others.

You helped me to understand the good way of disabling sprites.
I wrote "smart" method, but I should have wrote "a method that works both on
emulators and hardware, and that takes a processing minimal time for the
console".

I wanted to know how to disable a sprite without wasting rendering cycles.

Thanks to you I know that :

	 I can use the double-size flag.
	 Put the Y coord to 160.

You're right also when you say that there is no use to have disabled sprites
lower in OAM that enabled ones.

That why this little official note wanted to say, so.
It sounds clear to me now.

The only thing I regret, is that I don't know how you managed to get the
official header files
(unless you are official developpers) ;|


-----Original Message-----
From: Tom Prosser [mailto:tom@...]
Sent: mercredi 1 août 2001 18:57
To: 'gbadev@yahoogroups.com'
Subject: RE: [gbadev] Method to disable (hide) a sprite



That's what it means to me, so use the double-size flag instead.  Although
it's not mentioned in the manual, it's legal as, as groepaz says, it's
defined in AgbDefines.h as OAM_OBJ_OFF.

On the other hand, why would you have sprites off-screen that are lower in
OAM than on-screen ones anyway?


-----Original Message-----
From: Pierron, Christophe [mailto:CPierron@...]
Sent: 01 August 2001 12:57
To: 'gbadev@yahoogroups.com'
Subject: RE: [gbadev] Method to disable (hide) a sprite


Thank you
I've read from an official source that :

<<If the number for non-displayed (outside of the screen) OBJ in the OAM is
lower than that for displayed OBJ, the bigger the non-displayed OBJ's size
is, the less efficient the rendering will be. Please be aware of this
problem.>>

What does it mean to you ?
Does this mean that when we put too many objects outside of the displayable
screen
(for example Y = 160), the OBJ rendering performance is less efficient ?




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




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



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

Hello James,

Wednesday, August 01, 2001, 8:06:26 PM, you wrote:

JB> The only reason for doing this is so if the linker doesnt have somewhere to
JB> put an object, it can have a good guess from what the object and memory
JB> regions are marked as.

isnt everything that the linker doesnt know where to put it placed in
*(COMMON) ?

>> oh and at last.... why do you put AT(0x08000000) for text-section?
>> text-section will be the first thing in the final binary anyway =)
JB> Technically you dont need it... :)
JB> The AT just tells the linker where to put the data in the generated ROM. The
JB> other address is the address of the symbol.

yeah sure i know that... but the linker can get that info from the
memory-region the section is assigned to, no? ie, if you dont want to
force any other section than .text to be placed at the start of your
binary, you dont need the AT.

JB> This is all just so you can have code in ROM but referenced in RAM. It's
JB> then up to you to do relocation...

mmh, ive simply declared another memory-region and section for that,
works fine for me ;) (i have to admit i use most of the wram for data,
not code... and all code placed in valuable wram ist handcoded asm so
much less problems with the linker stuff ;=))


--
Best regards,
  groepaz                            mailto:groepaz@...

> If you are so great, please feel free to write the mother of all linker
> scripts and find some ingenious way of specifying segments for ARM code and
> THUMB code without GCC throwing a wobbly.

Did I really say anything to warrant this kind of response?  I only
critiqued your script, I felt that it would end up being more trouble than
its worth, a maintanence nightmare.  I never said "I'm better than you and
you suck", I said "There is a better way and I'm about to release this
better way"

I AM writing the "mother of all linker scripts," and I believe that all
this linker script nonsense is silly, its like asking people to write
their own assemblers and compilers.  I think that 99 percent of what
people want to do can be moved to a much higher level without much or any
lose of efficiency or control.  So 99 percent of people should never have
to touch their linker scripts.

I might be wrong, but if I'm right everyone can stop complaining "my
variables don't change" and "C++ doesn't work!" and "how do you copy
functions into internal wram" and all that and just worry about writing
game code.

On another note, When a person complains about putting const on stuff that
IS const, I can't help but get the impression that they care more about
how their code looks than how it works.

You are using your copy8 function to copy to VRAM, you not allowed to write
to VRAM in 8bits, only 16 and 32 so the next 8 is a copy of the first 8 and
so every second pixel is the same and giving that moasic effect.

so just merge every 2 u8's into u16 and then write it to the vram.


or something
> I'm trying to display a single sprite to the screen, but it looks
> like it always has some sort of mosaic effect enabled.
> I have a 32x64 sprite set up to display, but when the gba actually
> displays it, it displays every second pixel and then doubles that
> horizontally, resulting in a rather ugly sprite.
>
> Here is what I have so far (I'm not too worried about the garbage
> sprites at the moment):
>
> #include "gba_gfx.h"
> #include "sprites/test2.c"
>
> #define SPRITE_WIDTH     32
> #define SPRITE_HEIGHT    64
> #define SPRITE_BITS      8
>
> #define TILESET          0
> #define MAPSET           16
> #define TILE_SIZE        (8*8)
> #define SPRITE_SIZE      (SPRITE_WIDTH*SPRITE_HEIGHT)
> #define SPRITE_TILES     (SPRITE_SIZE / TILE_SIZE)
> #define SPRITE_NUM(A)    (((A)*SPRITE_TILES))
> #define SPRITE_OFFSET(A) (SPRITE_NUM(A)*TILE_SIZE)
>
> #define ATTR0_SHAPE_SQUARE 0
> #define ATTR0_SHAPE_RECTH  0x4000
> #define ATTR0_SHAPE_RECTV  0x8000
> #define ATTR0_COLOR_16     0
> #define ATTR0_COLOR_256    0x2000
> #define ATTR0_Y_COORD(A)   ((A)&0xff)
> #define ATTR0_FORCE_SPRITE_OFF 0x200
>
> #define ATTR1_SIZE_8       0
> #define ATTR1_SIZE_16      0x4000
> #define ATTR1_SIZE_32      0x8000
> #define ATTR1_SIZE_64      0xc000
> #define ATTR1_FLIP_X       0x1000
> #define ATTR1_FLIP_Y       0x2000
> #define ATTR1_X_COORD(A)   ((A)&0x1ff)
>
> #define ATTR2_TILE_NUMBER(A) ((A))
>
>
> void copy8(volatile u8* dst, volatile u8* src, u32 length)
> {
> while(length--)
> *dst++ = *src++;
> }
>
> void copy16(volatile u16* dst, volatile u16* src, u32 length)
> {
> while(length--)
> *dst++ = *src++;
> }
>
> int AgbMain(void)
> {
> volatile u8* pSpriteTiles   = (u8*)(ADDR_SPRITE_DATA);
> volatile u8* pSpritePalette = (u8*)ADDR_PALETTE_OBJ;
> volatile u16* psprite = (u16*)ADDR_OAM;
>
> copy16((u16*)pSpritePalette, (u16*)test2_Palette,
> 1<<SPRITE_BITS);
> copy8(pSpriteTiles(u8*)test2_Character, SPRITE_SIZE);
>
> *IO_DISPCNT = DISPCNT_VIDEO_MODE(0) | DISPCNT_SPRITES |
> DISPCNT_1D_MAPPING;
>
> *psprite++ = ATTR0_SHAPE_RECTV | ATTR0_COLOR_256 |
> ATTR0_Y_COORD(48);
> *psprite++ = ATTR1_SIZE_64 | ATTR1_X_COORD(104);
> *psprite++ = ATTR2_TILE_NUMBER(0);
> *psprite = 0;
>
> while(1);
>
> return 0;
> }
>
>
>
>
>
> list rules: http://www.gbadev.org/rules.txt
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

> I set the starting characters at
> (previous-sprite-start-location + size-of-sprite / (4*8))
>
> where size of sprite = 256 for a 16x16 sprite

why are you going size of sprite / 32? This will not be the number of tiles.
try size of sprite / 64.

i can confirm that, the first few lines of the screen can have weird color
marks on them if you are using alot of other sprites while still having most
of them up in the corner

> switching off the sprites by filling the OAM with zeros does _NOT_
> switch off the sprites. instead it places all sprites in the top left
> corner of the screen - these sprites are invisible but they do very
> well steal cycles from the rendering circuit, you will get funny
> errors when you try to display a bunch of visible sprites in the same
> Y area.

On Wed, 1 Aug 2001, Jeff Slutter wrote:

> What I did was add some code to my crt0.s for the irq handler.  You must
> write it in ARM code (.arm or .code 32).  I'm not sure if you have to
> save/restore registers, but I did.

You don't, the compiler has 3 seperate sets of registers for system, irq,
and swi modes.  I'm not sure of the details, but I am pretty sure that
your irq code can do whatever it wants with the registers because they
are not the same registers that are used for normal code.

Don't have the sprite area of VRAM declared as "u8".  Declare it as "u16",
and copy your sprite data 16 bits at a time (typecast your source data to
u16 if you can't re-convert it to that and try to ensure it is aligned to 16
bits).  Sprite VRAM is like all other VRAM - you cannot write to it 8 bits
at a time, otherwise the same 8 bits get repeated across two pixels, and I'm
guessing that's what you're seeing.


-----Original Message-----
From: Karl Stenerud [mailto:kstenerud@...]
Sent: 01 August 2001 17:30
To: gbadev@yahoogroups.com
Subject: [gbadev] Sprite just won't display properly.


I'm trying to display a single sprite to the screen, but it looks
like it always has some sort of mosaic effect enabled.
I have a 32x64 sprite set up to display, but when the gba actually
displays it, it displays every second pixel and then doubles that
horizontally, resulting in a rather ugly sprite.

Here is what I have so far (I'm not too worried about the garbage
sprites at the moment):

#include "gba_gfx.h"
#include "sprites/test2.c"

#define SPRITE_WIDTH     32
#define SPRITE_HEIGHT    64
#define SPRITE_BITS      8

#define TILESET          0
#define MAPSET           16
#define TILE_SIZE        (8*8)
#define SPRITE_SIZE      (SPRITE_WIDTH*SPRITE_HEIGHT)
#define SPRITE_TILES     (SPRITE_SIZE / TILE_SIZE)
#define SPRITE_NUM(A)    (((A)*SPRITE_TILES))
#define SPRITE_OFFSET(A) (SPRITE_NUM(A)*TILE_SIZE)

#define ATTR0_SHAPE_SQUARE 0
#define ATTR0_SHAPE_RECTH  0x4000
#define ATTR0_SHAPE_RECTV  0x8000
#define ATTR0_COLOR_16     0
#define ATTR0_COLOR_256    0x2000
#define ATTR0_Y_COORD(A)   ((A)&0xff)
#define ATTR0_FORCE_SPRITE_OFF 0x200

#define ATTR1_SIZE_8       0
#define ATTR1_SIZE_16      0x4000
#define ATTR1_SIZE_32      0x8000
#define ATTR1_SIZE_64      0xc000
#define ATTR1_FLIP_X       0x1000
#define ATTR1_FLIP_Y       0x2000
#define ATTR1_X_COORD(A)   ((A)&0x1ff)

#define ATTR2_TILE_NUMBER(A) ((A))


void copy8(volatile u8* dst, volatile u8* src, u32 length)
{
       while(length--)
             *dst++ = *src++;
}

void copy16(volatile u16* dst, volatile u16* src, u32 length)
{
       while(length--)
             *dst++ = *src++;
}

int AgbMain(void)
{
       volatile u8* pSpriteTiles   = (u8*)(ADDR_SPRITE_DATA);
       volatile u8* pSpritePalette = (u8*)ADDR_PALETTE_OBJ;
       volatile u16* psprite = (u16*)ADDR_OAM;

       copy16((u16*)pSpritePalette, (u16*)test2_Palette,
1<<SPRITE_BITS);
       copy8(pSpriteTiles(u8*)test2_Character, SPRITE_SIZE);

       *IO_DISPCNT = DISPCNT_VIDEO_MODE(0) | DISPCNT_SPRITES |
DISPCNT_1D_MAPPING;

       *psprite++ = ATTR0_SHAPE_RECTV | ATTR0_COLOR_256 |
ATTR0_Y_COORD(48);
       *psprite++ = ATTR1_SIZE_64 | ATTR1_X_COORD(104);
       *psprite++ = ATTR2_TILE_NUMBER(0);
       *psprite = 0;

       while(1);

       return 0;
}




list rules: http://www.gbadev.org/rules.txt
<http://www.gbadev.org/rules.txt>
unsubscribe: gbadev-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to the Yahoo!
<http://docs.yahoo.com/info/terms/> Terms of Service.




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

Hello Tom,

Wednesday, August 01, 2001, 2:17:24 PM, you wrote:


TP> What's wrong with it?  It's about the "smartest" solution I've seen - it
TP> seems to completely switch off the sprite, whereas moving the Y value to 160
TP> means you also have to ensure that the sprite is not high enough to wrap
TP> around to the top of the screen.

switching off the sprites by filling the OAM with zeros does _NOT_
switch off the sprites. instead it places all sprites in the top left
corner of the screen - these sprites are invisible but they do very
well steal cycles from the rendering circuit, you will get funny
errors when you try to display a bunch of visible sprites in the same
Y area.

--
Best regards,
  groepaz                            mailto:groepaz@...

> Your solution seems likely to cause so many other problems :)
> .data should be writable, so you should not put its VMA in ROM

In our setup it wasnt. Allowing data to be writable caused far more
problems. I'm not going through all the code marking stuff as const when
there is no need...

> How do you clear the bss section when you don't PROVIDE symbols for it.

If you clear all work ram then the BSS is cleared... as most people do. ??

> Heck, what happens to data in .ao files?

Data in .ao files is added to the end of rom. It works it out from the
memory definitions.

> You should declare iwram to be smaller than it is to leave room for stack.

True.

> C++ couldn't possibly work with this script.

True. We dont use it, hence I dont support it.

> Doing things in linker scripts with specific file names or extensions is
> too hacky for me.  Although extensions seem less hacky than whole
> filenames (this is just my opinion however).

It's the least hacky way I have found. If there is a more magical way, let
others know.

Specifying different segments to different functions was a pain in the arse
and caused more problems.

It may be hacky, but it works.

> I come to the conclusion that your simple linker script is too simple ^_^

It works for me, if it doesnt work for you, fix it.

It was put out as an example of how to get code to run -- which many people
have had problems with.

If you can do better, please feel free to share it with everyone.

> I'd tell you to go back to the drawing board, but Jeff should be releasing
> a lnkscript soon which does everything right (well, at least one version

Um, works for me 100%. It was never supposed to be a be all and end all of
linker scripts, I was being thoughtfull and providing other people a
building block to work on.

If you are so great, please feel free to write the mother of all linker
scripts and find some ingenious way of specifying segments for ARM code and
THUMB code without GCC throwing a wobbly.

Best of luck.

--Jim

What I did was add some code to my crt0.s for the irq handler.  You must
write it in ARM code (.arm or .code 32).  I'm not sure if you have to
save/restore registers, but I did.  I call my c code interrupt handler
(which is in thumb code) to do the real stuff.

The interrupt actually happens when a timer rolls over (65535 to 0), so make
sure you enable the timer, and set the irq enable on it.

Here is some code:

#define TIMER0_IRQ 3
#define TIMER1_IRQ 4
#define TIMER2_IRQ 5
#define TIMER3_IRQ 6
#define REG_IME         *(volatile uint16*)0x4000208
#define REG_IE         *(volatile uint16*)0x4000200
#define REG_IF         *(volatile uint16*)0x4000202
#define REG_TM0D       *(volatile uint16*)0x4000100
#define REG_TM0CNT     *(volatile uint16*)0x4000102
#define REG_TM1D       *(volatile uint16*)0x4000104
#define REG_TM1CNT     *(volatile uint16*)0x4000106
#define REG_TM2D       *(volatile uint16*)0x4000108
#define REG_TM2CNT     *(volatile uint16*)0x400010A
#define REG_TM3D       *(volatile uint16*)0x400010C
#define REG_TM3CNT     *(volatile uint16*)0x400010E
#define TIM_IRQ_ENABLE      (1 << 6)


typedef struct
{
  uint32 r00,r01,r02,r03,r04,r05,r06,r07,r08,r09,r10;
  uint32 r11,r12,sp,lr;
}reg_list;

enabling irq for timer0
REG_IME     = 0; // disable master irq
REG_IE     |= (1 << TIMER0_IRQ); // enable timer0 irq
REG_TM0D    = 0; // set timer 0 value
REG_TM0CNT |= TIM_IRQ_ENABLE; // make timer 0 trigger an irq, done't forget
to setup the timer and enable it
REG_IME     = 1; // enable master irq

handling an interrupt (c code)
void _gba_interrupt_handler(reg_list *regs)
{
  uint16 irqs = REG_IF;
  uint32 set = (irqs & (1 << TIMER0_IRQ));
  if(set)
  {
   // PROCESS INTERRUPT FOR TIMER 0 here
  }

  // clear irq flags
  REG_IF = irqs;

  // re-enable them
  REG_IE |= irqs;
}

asm code for irq handling (note: it seems stmia and ldmia are broken on
Mappy):
  .CODE 32
  .ALIGN 2
  .EXTERN _gba_interrupt_handler
  .GLOBL _arm_irq_handler
  .TYPE _arm_irq_handler,function

_arm_irq_handler:
  @ save registers
  str r0, [sp, #-4]!
  str lr, [sp, #-4]!
  sub sp, sp, #15*4
  stmia sp, {r0 - lr}^
  mov r0, sp

  @ call the interrupt handler
  bl  _gba_interrupt_handler

  @ restore registers
  ldmia sp, {r0 - lr}^
  mov r0, r0
  ldr lr, [sp, #15*4]
  add sp, sp, #15*4+8

  bx  lr

> whats that (wx) / (rx) attribute ? is that to mark entire memory
> regions as read-only or writeable? (and uhm... WHY you do this that

Yep. W = read/write and X = execute.

The only reason for doing this is so if the linker doesnt have somewhere to
put an object, it can have a good guess from what the object and memory
regions are marked as.

> *.o    => refers to all object files, regardless what they contain
> (or should this be *.o(*) or sth !?)
> *.o(.data) => refers to all sections marked as data in all object
> files

Yes. *(*) would be all files, all segments. *.o(.code) would be all code
segments of *.o files.

> oh and at last.... why do you put AT(0x08000000) for text-section?
> text-section will be the first thing in the final binary anyway =)

Technically you dont need it... :)

The AT just tells the linker where to put the data in the generated ROM. The
other address is the address of the symbol.

This is all just so you can have code in ROM but referenced in RAM. It's
then up to you to do relocation...

Cheers!

--Jim

> On Tue, 31 Jul 2001, Stephane Magnenat wrote:
> I have the 64 MB version. It works fine on win2k, and also works fine on
ripping on GNU/Linux.
> But I can't make it work on writing with Linux. It writes, says ok,
verification succeed; but the GBA cannot boot the flash card and when I put it
back on win2k, the program says that the flash headers are corrputed, and ask me
to fix them.
> Does someone has any idea on why this happens ?

If you're using Jeff Frohwein's flinker, the reason is that Jeff hasn't
implemented header correction yet.

I believe you can use a tool such as gbafix (http://credo.resource.cx/)
to do this in the meantime.

-D

That's what it means to me, so use the double-size flag instead.  Although
it's not mentioned in the manual, it's legal as, as groepaz says, it's
defined in AgbDefines.h as OAM_OBJ_OFF.

On the other hand, why would you have sprites off-screen that are lower in
OAM than on-screen ones anyway?


-----Original Message-----
From: Pierron, Christophe [mailto:CPierron@...]
Sent: 01 August 2001 12:57
To: 'gbadev@yahoogroups.com'
Subject: RE: [gbadev] Method to disable (hide) a sprite


Thank you
I've read from an official source that :

<<If the number for non-displayed (outside of the screen) OBJ in the OAM is
lower than that for displayed OBJ, the bigger the non-displayed OBJ's size
is, the less efficient the rendering will be. Please be aware of this
problem.>>

What does it mean to you ?
Does this mean that when we put too many objects outside of the displayable
screen
(for example Y = 160), the OBJ rendering performance is less efficient ?




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

Hi,
> > I've already saw articles talking about the double - size flag, but it
seems
> > not to be a really "smart" solution.

There are many ways to make a sprite non-visible, but only one way to "turn
it off". This is done by setting the double-size flag and clearing the
rot/scale flag. It has nothing to do with being smart, it is the way the
hardware works :).

> easiest and legal way is setting the y coordinate to 160

Easiest way to make it non-visible is setting the y to 160. In this case,
you remove it from scan-line obj calculations, and achieve a similar effect
to the double-size/rot-scale switch.

Legal???? ;)

     Just Me,
         *SF

I'm trying to display a single sprite to the screen, but it looks
like it always has some sort of mosaic effect enabled.
I have a 32x64 sprite set up to display, but when the gba actually
displays it, it displays every second pixel and then doubles that
horizontally, resulting in a rather ugly sprite.

Here is what I have so far (I'm not too worried about the garbage
sprites at the moment):

#include "gba_gfx.h"
#include "sprites/test2.c"

#define SPRITE_WIDTH     32
#define SPRITE_HEIGHT    64
#define SPRITE_BITS      8

#define TILESET          0
#define MAPSET           16
#define TILE_SIZE        (8*8)
#define SPRITE_SIZE      (SPRITE_WIDTH*SPRITE_HEIGHT)
#define SPRITE_TILES     (SPRITE_SIZE / TILE_SIZE)
#define SPRITE_NUM(A)    (((A)*SPRITE_TILES))
#define SPRITE_OFFSET(A) (SPRITE_NUM(A)*TILE_SIZE)

#define ATTR0_SHAPE_SQUARE 0
#define ATTR0_SHAPE_RECTH  0x4000
#define ATTR0_SHAPE_RECTV  0x8000
#define ATTR0_COLOR_16     0
#define ATTR0_COLOR_256    0x2000
#define ATTR0_Y_COORD(A)   ((A)&0xff)
#define ATTR0_FORCE_SPRITE_OFF 0x200

#define ATTR1_SIZE_8       0
#define ATTR1_SIZE_16      0x4000
#define ATTR1_SIZE_32      0x8000
#define ATTR1_SIZE_64      0xc000
#define ATTR1_FLIP_X       0x1000
#define ATTR1_FLIP_Y       0x2000
#define ATTR1_X_COORD(A)   ((A)&0x1ff)

#define ATTR2_TILE_NUMBER(A) ((A))


void copy8(volatile u8* dst, volatile u8* src, u32 length)
{
	 while(length--)
		 *dst++ = *src++;
}

void copy16(volatile u16* dst, volatile u16* src, u32 length)
{
	 while(length--)
		 *dst++ = *src++;
}

int AgbMain(void)
{
	 volatile u8* pSpriteTiles   = (u8*)(ADDR_SPRITE_DATA);
	 volatile u8* pSpritePalette = (u8*)ADDR_PALETTE_OBJ;
	 volatile u16* psprite = (u16*)ADDR_OAM;

	 copy16((u16*)pSpritePalette, (u16*)test2_Palette,
1<<SPRITE_BITS);
	 copy8(pSpriteTiles(u8*)test2_Character, SPRITE_SIZE);

	 *IO_DISPCNT = DISPCNT_VIDEO_MODE(0) | DISPCNT_SPRITES |
DISPCNT_1D_MAPPING;

	 *psprite++ = ATTR0_SHAPE_RECTV | ATTR0_COLOR_256 |
ATTR0_Y_COORD(48);
	 *psprite++ = ATTR1_SIZE_64 | ATTR1_X_COORD(104);
	 *psprite++ = ATTR2_TILE_NUMBER(0);
	 *psprite = 0;

	 while(1);

	 return 0;
}

On Wed, 1 Aug 2001, James Boulton wrote:

> Right, here's a working solution for putting ARM code in WRAM:

Your solution seems likely to cause so many other problems :)

.data should be writable, so you should not put its VMA in ROM

How do you clear the bss section when you don't PROVIDE symbols for it.

How do you put data into iwram?

Heck, what happens to data in .ao files?

You should declare iwram to be smaller than it is to leave room for stack.

C++ couldn't possibly work with this script.

Doing things in linker scripts with specific file names or extensions is
too hacky for me.  Although extensions seem less hacky than whole
filenames (this is just my opinion however).

I come to the conclusion that your simple linker script is too simple ^_^

I'd tell you to go back to the drawing board, but Jeff should be releasing
a lnkscript soon which does everything right (well, at least one version
of "right," we hope) and I'll be putting it into devkit-advance.  It at
least should be a good starting point for any linker script hacking if you
require something different than a well behaved baseline.

How do you setup a Timer Interrupt Handler on the GBA?
I am having problems getting it to work.

Thanks

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

Hello James,

Wednesday, August 01, 2001, 1:42:02 PM, you wrote:

JB> Right, here's a working solution for putting ARM code in WRAM:
JB> Use a simple linker script which looks something like this:

[snip]

nice to see atleast some ppl bother to dig into this stuff ;=)

got two little questions though, never used these options myself (but
you can never know if they could be useful sometime eh? ;))

JB> MEMORY
JB> {
JB>  iram (wx) : ORIGIN = 0x3000000, LENGTH = 32K
JB>  eram (wx) : ORIGIN = 0x2000000, LENGTH = 256K
JB>  rom  (rx) : ORIGIN = 0x8000000, LENGTH = 8M
JB> }

whats that (wx) / (rx) attribute ? is that to mark entire memory
regions as read-only or writeable? (and uhm... WHY you do this that
way? wouldnt it be the same if you'd leave those out and take care
about that yourself -in the script- so sections end up where they
belong? will the linker issue warnings/errors if you try to put eg
data section in a memory region marked as read-only?)

JB>  .text : AT(0x8000000)
JB>  {
JB>   *.o(.text)
JB>   *(.data)
JB>   *(.rodata)
JB>      *(.glue_7t)
JB>   *(.glue_7)
JB>  }
JB>  > rom

do i take that right that anything without paranthesis in a
section-definition refers to a file and everything in paranthesis
refers to a section? so

*.o    => refers to all object files, regardless what they contain
(or should this be *.o(*) or sth !?)
*.o(.data) => refers to all sections marked as data in all object
files

oh and at last.... why do you put AT(0x08000000) for text-section?
text-section will be the first thing in the final binary anyway =)

--
Best regards,
  groepaz                            mailto:groepaz@...

What's wrong with it?  It's about the "smartest" solution I've seen - it
seems to completely switch off the sprite, whereas moving the Y value to 160
means you also have to ensure that the sprite is not high enough to wrap
around to the top of the screen.

-----Original Message-----
From: Pierron, Christophe [mailto:CPierron@...]
Sent: 01 August 2001 13:14
To: Tom Prosser
Subject: [gbadev] Method to disable (hide) a sprite


Is there an easy method to disable (hide) a sprite on the GBA ?

Actually, when I do not use an OAM entry, I fill it with 0.
In sprite RAM, the first 8 x 8 block I put is filled with 0.

But I think there is a limitation on the maximum displayable sprites per
line,
even if these sprites are fully 8 x 8 transparent blocks ?

I've already saw articles talking about the double - size flag, but it seems
not to be a really "smart" solution.


list rules: http://www.gbadev.org/rules.txt
<http://www.gbadev.org/rules.txt>
unsubscribe: gbadev-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to the Yahoo!
<http://docs.yahoo.com/info/terms/> Terms of Service.




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

Hi everyone

I really feel bad posting this once again ;
but since the last time ; I haven't managed to get it to work
proparly :
sprite 0 always comes out perfectly
sprite 1 has it's top cut off but the rest is ok
and sprite 2 simply apears blank    ....grrrrrrr

I set the starting characters at
(previous-sprite-start-location + size-of-sprite / (4*8))

where size of sprite = 256 for a 16x16 sprite

as posted in previous posts but the pb remains
here's my problematic code I guess :
///////////////////////////////////////////////////////////
InitializeSprites();  //set all 128 sprites to offscreen

sprites[0].attribute0 = COLOR_256 | SQUARE | y_ball;
sprites[0].attribute1 = SIZE_16 | x_ball;
sprites[0].attribute2 =  0;  //first sprite

sprites[1].attribute0 = COLOR_256 | SQUARE | y_boy1;
sprites[1].attribute1 = SIZE_32 | x_boy1;
sprites[1].attribute2 = 8;  //second sprite 0 + 128/16 = 8

sprites[2].attribute0 = COLOR_256 | y_plot1;
sprites[2].attribute1 = SIZE_16 | x_plot1;
sprites[2].attribute2 = 40; // third sp 8+(512 / 16)= 8 + 32 = 40

//OBJ_MAP_1D
for(loop = 0; loop < 128; loop++)
		 {
			 OAMData[loop] = ball16Data[loop];
		 }//end loop loop
for(loop= 128; loop < 641; loop++)
		 {
			 OAMData[loop] = blueboy32Data[loop];
		 }//end loop loop
for(loop = 641 ; loop < 769; loop++)
		 {
			 OAMData[loop] = plotData[loop];
		 }//end loop loop
////////////////////////////////////////////
If anybody has a clue of what's going on in this guys(*gba* or mine)
head pleaze feel free to operate...

Thanx in advance
Tib

Thank you
I've read from an official source that :

<<If the number for non-displayed (outside of the screen) OBJ in the OAM is
lower than that for displayed OBJ, the bigger the non-displayed OBJ's size
is, the less efficient the rendering will be. Please be aware of this
problem.>>

What does it mean to you ?
Does this mean that when we put too many objects outside of the displayable
screen
(for example Y = 160), the OBJ rendering performance is less efficient ?


-----Original Message-----
From: Manfred Linzner [mailto:linzner@...]
Sent: mercredi 1 août 2001 13:38
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] Method to disable (hide) a sprite


> I've already saw articles talking about the double - size flag, but it
seems
> not to be a really "smart" solution.

easiest and legal way is setting the y coordinate to 160

--

Manfred Linzner
(Project Manager)
Shin'en Multimedia
http://www.shinen.com
Tel.: ++49 (0)89 785 82 565
Fax.: ++49 (0)89 785 82 535

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




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



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

Hello Manfred,

Wednesday, August 01, 2001, 1:37:51 PM, you wrote:

>> I've already saw articles talking about the double - size flag, but it seems
>> not to be a really "smart" solution.

ML> easiest and legal way is setting the y coordinate to 160


the double-size flag seems to be perfectly "legal" though (somewhere
in N's headers its even defined as "sprite off" or sth)


--
Best regards,
  groepaz                            mailto:groepaz@...

Right, here's a working solution for putting ARM code in WRAM:

Use a simple linker script which looks something like this:

OUTPUT_FORMAT("elf32-littlearm", "elf32-bigarm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)

MEMORY
{
  iram (wx) : ORIGIN = 0x3000000, LENGTH = 32K
  eram (wx) : ORIGIN = 0x2000000, LENGTH = 256K
  rom  (rx) : ORIGIN = 0x8000000, LENGTH = 8M
}

SECTIONS
{
  .bss :
  {
   *(.bss)
  }
  > iram

  .text : AT(0x8000000)
  {
   *.o(.text)
   *(.data)
   *(.rodata)
      *(.glue_7t)
   *(.glue_7)
  }
  > rom

  .armcode : AT(ADDR(.text) + SIZEOF(.text))
  {
   _sdata = .;
   *.ao(.text);
   _edata  =  .;
  }
  > iram
  _datalma = LOADADDR(.armcode);

  PROVIDE (end = .);

  .stab . (NOLOAD) :
  {
   [ .stab ]
  }
  .stabstr . (NOLOAD) :
  {
   [ .stabstr ]
  }
}

This puts all .o files in the ROM, including all code and data (Sorry, no
initialised global support. You have to do that yourself...).

It also puts all .ao files in work RAM after the global variables (BSS).
These are you ARM files! Make sure you compile all ARM code to .ao object
files for this to work...

All you need to do now is copy the code to work RAM using something like
this in your crt0.s (nicked from Jeff's code):

@-- COPY INITIALISED DATA / CODE TO RAM

         ldr     r1,=_edata
         ldr     r2,=_sdata
         subs    r3,r1,r2         @ Is there any data to copy?
         beq     CIDSkip          @ no

         ldr     r1,=_datalma
CIDLoop:
         ldmia   r1!,{r0}
         stmia   r2!,{r0}
         subs    r3,r3,#4
         bne     CIDLoop

CIDSkip:

Then jump to your main here...

That's it!

Oh, except GCC is crap at working out how to call stuff, so you have to call
ALL your ARM functions via function pointers. Likewise if you want to call
THUMB function from the ARM code you have to use a function pointer.

Not sure about the ARM compiler. Will look into it later... :)

Cheers,

--Jim

> I've already saw articles talking about the double - size flag, but it seems
> not to be a really "smart" solution.

easiest and legal way is setting the y coordinate to 160

--

Manfred Linzner
(Project Manager)
Shin'en Multimedia
http://www.shinen.com
Tel.: ++49 (0)89 785 82 565
Fax.: ++49 (0)89 785 82 535

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

Is there an easy method to disable (hide) a sprite on the GBA ?

Actually, when I do not use an OAM entry, I fill it with 0.
In sprite RAM, the first 8 x 8 block I put is filled with 0.

But I think there is a limitation on the maximum displayable sprites per
line,
even if these sprites are fully 8 x 8 transparent blocks ?

I've already saw articles talking about the double - size flag, but it seems
not to be a really "smart" solution.