--- In gbadev@y..., Collin van Ginkel <collin@t...> wrote:
> Hi,
>
> We're experiencing the same 'error' here. We've also ordered the NTSC
> version and are using it in the Netherlands (PAL territory) and now
> know, thanks to your mail, it's not a PAL-problem..
>
> I'd imagine it's a problem with a slighty different refresh rate, but
> I'd couldn't say for sure.

GBA generates about 59.73 (2^24 / 280896) Hz vertical refresh.

NTSC TV uses about 59.94 (60000 / 1001) Hz vertical refresh.

The difference is 0.213 Hz.  You will get a bar rolling down the
screen about every 4.7 seconds.

--
Damian

NTSC refreshrate 59,94 fps
GBA refreshrate 59.727 fps

But I'm not gonna do make any conclusions from this, I don't know the
TV-De-Advance :-)

-----Original Message-----
From: simonclarke [mailto:simonclarke@...]
Sent: Samstag, 07. September 2002 23:37
To: gbadev@yahoogroups.com
Subject: [gbadev] GBA and TV De Advance - Display Not Synchronized?


I'm using the TV-De-Advance (see www.lik-sang.com) to display output
from the GBA on a TV.

I did a simple test, alternating the background between two colors
(red and black) every frame, and noticed a small rolling black band
every couple of seconds.

I couldn't think what was causing this - there were no other
interrupts enabled, or things getting in the way etc.

Then I looked at the actual GBA screen, and this black band never
appeared.

Does anybody have any thoughts or comments on this?

I would have thought with the ~60Hz output of the GBA, the TV-De-
Advance would have no problem keeping up with being able to generate
the correct NTSC sync signals, and so I would see a rock solid
display on the TV.

We're in the U.S. and I believe we ordered NTSC units. If we received
PAL TV-De-Advances in error, wouldn't a rolling black band show up
more often than every two seconds?

I remember a while back, doing a similar test on Nintendo's WideBoy
(their official solution to viewing GBA output) and there was no
rolling band.

Simon.






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

Hi,

We're experiencing the same 'error' here. We've also ordered the NTSC
version and are using it in the Netherlands (PAL territory) and now
know, thanks to your mail, it's not a PAL-problem..

I'd imagine it's a problem with a slighty different refresh rate, but
I'd couldn't say for sure.

Greetz,

Collin

On zaterdag, sep 7, 2002, at 23:36 Europe/Amsterdam, simonclarke wrote:

> I'm using the TV-De-Advance (see www.lik-sang.com) to display output
> from the GBA on a TV.
>
> I did a simple test, alternating the background between two colors
> (red and black) every frame, and noticed a small rolling black band
> every couple of seconds.
>
> I couldn't think what was causing this - there were no other
> interrupts enabled, or things getting in the way etc.
>
> Then I looked at the actual GBA screen, and this black band never
> appeared.
>
> Does anybody have any thoughts or comments on this?
>
> I would have thought with the ~60Hz output of the GBA, the TV-De-
> Advance would have no problem keeping up with being able to generate
> the correct NTSC sync signals, and so I would see a rock solid
> display on the TV.
>
> We're in the U.S. and I believe we ordered NTSC units. If we received
> PAL TV-De-Advances in error, wouldn't a rolling black band show up
> more often than every two seconds?
>
> I remember a while back, doing a similar test on Nintendo's WideBoy
> (their official solution to viewing GBA output) and there was no
> rolling band.
>
> Simon.

I'm using the TV-De-Advance (see www.lik-sang.com) to display output
from the GBA on a TV.

I did a simple test, alternating the background between two colors
(red and black) every frame, and noticed a small rolling black band
every couple of seconds.

I couldn't think what was causing this - there were no other
interrupts enabled, or things getting in the way etc.

Then I looked at the actual GBA screen, and this black band never
appeared.

Does anybody have any thoughts or comments on this?

I would have thought with the ~60Hz output of the GBA, the TV-De-
Advance would have no problem keeping up with being able to generate
the correct NTSC sync signals, and so I would see a rock solid
display on the TV.

We're in the U.S. and I believe we ordered NTSC units. If we received
PAL TV-De-Advances in error, wouldn't a rolling black band show up
more often than every two seconds?

I remember a while back, doing a similar test on Nintendo's WideBoy
(their official solution to viewing GBA output) and there was no
rolling band.

Simon.

I don't want to sound like I'm doing a promotional bit or something,
but for anyone wanting to add music to their games/demos, I do think
that the Krawall SDK is quite good considering the price - and the
fact that I don't know of anything comparable out there that also has
a free non-commercial version.  The pay versions are also *very*
inexpensive, enough that you might as well just buy it.  So far I am
quite happy . . . Also, I rarely find myself using more than 12
channels at a time, and even this is because of my sloppy tracking.

Tom

--- In gbadev@y..., Sebastian Kienzl <zap@r...> wrote:
> On Fri, 6 Sep 2002 17:26:04 +0100 Martin Piper <martinp@a...> wrote:
> > "Lego Bionicle: Matoran Adventures" due out next month uses a 32
channel
> > player and uses 40% CPU when doing this.
>
> Well, theoretically Krawall can mix 32 channels with less than 40% usage
> (2.6 + 32*1.13) too, provided that these channels are panned far
left or right
> or mono-playback is selected.
> I don't think we need to get into a "who's got the longest"-discussion
> here, 32 *are* many channels for a system like that.
>
> Yours,
> Sebastian Kienzl

On Fri, 6 Sep 2002 17:26:04 +0100 Martin Piper <martinp@...> wrote:

> "Lego Bionicle: Matoran Adventures" due out next month uses a 32 channel
> player and uses 40% CPU when doing this. So I don't think it's over kill
> in the slightest. ;-)

Well, theoretically Krawall can mix 32 channels with less than 40% usage
(2.6 + 32*1.13) too, provided that these channels are panned far left or right
or mono-playback is selected.
I don't think we need to get into a "who's got the longest"-discussion
here, 32 *are* many channels for a system like that.

Yours,
Sebastian Kienzl

"Lego Bionicle: Matoran Adventures" due out next month uses a 32 channel
player and uses 40% CPU when doing this. So I don't think it's over kill in
the slightest. ;-)


-----Original Message-----
From: Sebastian Kienzl [mailto:zap@...]
Sent: 06 September 2002 16:15
To: gbadev@yahoogroups.com
Subject: Re[2]: [gbadev] Krawall free SDK final version


On Fri, 6 Sep 2002 11:58:40 +0100 Martin Piper <martinp@...> wrote:

Hi!

> The demo isn't too bad but you don't have any 32 channel music included.
> Can
> you add a 32 channel track to the download? 'whispers.xm' is a good
> example
> or 'RPG_BOSS.XM'. Both can be downloaded from http://www.glofi.com/

For a simple reason, Krawall can't handle 32 channels at once, 24 is the
max in the current implementation.
Besides using 32 channels on the GBA is quite an overkill since 20 channels
already take up approx 40% of the CPU-time and who would want to spend even
more CPU for music?
In my opinion even 20 channels are too many for a system like the GBA,
you can do an awful lot of music in <16 channels.
Sure, for special applications it easily could be raised to 32 channels (or
more) but I don't think this would be a standard application.

Yours,
Sebastian Kienzl







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

On Fri, 6 Sep 2002 11:58:40 +0100 Martin Piper <martinp@...> wrote:

Hi!

> The demo isn't too bad but you don't have any 32 channel music included.
> Can
> you add a 32 channel track to the download? 'whispers.xm' is a good
> example
> or 'RPG_BOSS.XM'. Both can be downloaded from http://www.glofi.com/

For a simple reason, Krawall can't handle 32 channels at once, 24 is the
max in the current implementation.
Besides using 32 channels on the GBA is quite an overkill since 20 channels
already take up approx 40% of the CPU-time and who would want to spend even
more CPU for music?
In my opinion even 20 channels are too many for a system like the GBA,
you can do an awful lot of music in <16 channels.
Sure, for special applications it easily could be raised to 32 channels (or
more) but I don't think this would be a standard application.

Yours,
Sebastian Kienzl

The demo isn't too bad but you don't have any 32 channel music included. Can
you add a 32 channel track to the download? 'whispers.xm' is a good example
or 'RPG_BOSS.XM'. Both can be downloaded from http://www.glofi.com/



-----Original Message-----
From: Sebastian Kienzl [mailto:zap@...]
Sent: 06 September 2002 11:51
To: gbadev@yahoogroups.com
Subject: [gbadev] Krawall free SDK final version


Hi!

I've now released the final version of the free Krawall SDK.
Krawall is still a library for replaying XM's and S3M's, however only the
latter is available in the free version.

You can download it at:
http://mind.riot.org/krawall/

Have fun,
Sebastian Kienzl







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

Hi!

I've now released the final version of the free Krawall SDK.
Krawall is still a library for replaying XM's and S3M's, however only the
latter is available in the free version.

You can download it at:
http://mind.riot.org/krawall/

Have fun,
Sebastian Kienzl

>I really see no point to this as you can access the entire video ram by
>setting your base block to zero.  Since tile numbers are 0-1023 that's
>all 64KB of memory.
[...]

That's only valid with 256 color backgrounds.
You can access only 32KB of video memory with 10 bits indexes in 16 colors.

er - you are incorrect.. 1 16 colour char is 32 bytes not 64 so you can
actually only access half of video ram (32 * 1024 = 32768 bytes or 32k) in
16 colour mode so being able to change the base address IS useful :)

we use a lot more than 1024 16 colour chars in our backgrounds and different
layers access different areas of vram - using 256 colour chars is wasteful
(and limits you to only 1024 chars)

also - what if you want to mix 16 and 256 colour chars? by using separate
bank offsets for each layer you don't limit yourself to using the same area
of vram for both tile sets.

and for rotation/scaling backgrounds the base offset is EXTREMELY useful
allowing you to access more than 256 chars if you have 2 rotation layers!

there are all sorts of situations where just having a single base for your
chars is not the best solution...

ninge
   -----Original Message-----
   From: JASON [mailto:dovoto@...]
   Sent: 05 September 2002 23:26
   To: gbadev@yahoogroups.com
   Subject: RE: [gbadev] how to use 2 char block on the same bg?!?


   >you would need to use a hblank to change the char base block value at
   the correct position down >the screen. either that or use two layers and
   have the first set to the first char block (showing >the top half) and
   the second set to display the second char block (showing the bottom
   half)

   I really see no point to this as you can access the entire video ram by
   setting your base block to zero.  Since tile numbers are 0-1023 that's
   all 64KB of memory.  The only time "bank switching" would be necessary
   is if you have more than 1024 tiles on screen at the same time and that
   is only possible using multiple layers of 16 color background tiles.
   Changing the charbase block during the hblank is never necessary unless
   you are trying to do some special effect or split mode operation.  I
   have heard it said that tile numbers use even-indexing (like sprites in
   256 color mode) and I do not know where this misconception is from but
   it is not true.   The simplest form of memory management is to use only
   character base block zero when using 256 color backgrounds and load the
   map data (indexes) to the upper portion of video memory.   This assures
   that character data and map index data never overlap and allows complete
   access to all available tile space.
   -jason

   www.thepernproject.com

I'm not sure what's causing these problems but DMA is giving me a lot
of headaches. Basically, consecutive DMAs seem to be screwing up.
Using Mappy I can see that DMAs are firing, but sometimes they don't
transfer the right info. For example, I have a function LoadMapData
(), it takes a pointer, a word count, and a destination to load the
tile map into. I call it twice, the first time I fill the map with
info for layer0, the second time for layer1... I look in memory and I
see at both blocks in memory the info from layer1.

This seems like such an elementary problem, but I have no idea why it
is happening. As near as I can tell when I do consecutive DMAs the
DMA doesn't start for a bit, and when it does start I've already
changed the source and/or dest regs with the addresses for the next
transfer.

I have no idea how to prevent this... I really can't do unrelated
stuff between this unless I invent some useless code to stick in. I
have the calls to DMA wrapped in functions, but this doesn't seem to
introduce a delay. For each DMA I set the source, dest, control +
enable, and lastly word count regs in that order, but that doesn't
seem to introduce the desired delay.

If I'm doing something wrong or if anyone has a tried and tested
function of theirs for DMA that works I'd appreciate having a look at
it. If you think that my problem is something else, by all means,
chime in.

Thanks.

>you would need to use a hblank to change the char base block value at
the correct position down >the screen. either that or use two layers and
have the first set to the first char block (showing >the top half) and
the second set to display the second char block (showing the bottom
half)

I really see no point to this as you can access the entire video ram by
setting your base block to zero.  Since tile numbers are 0-1023 that's
all 64KB of memory.  The only time "bank switching" would be necessary
is if you have more than 1024 tiles on screen at the same time and that
is only possible using multiple layers of 16 color background tiles.
Changing the charbase block during the hblank is never necessary unless
you are trying to do some special effect or split mode operation.  I
have heard it said that tile numbers use even-indexing (like sprites in
256 color mode) and I do not know where this misconception is from but
it is not true.   The simplest form of memory management is to use only
character base block zero when using 256 color backgrounds and load the
map data (indexes) to the upper portion of video memory.   This assures
that character data and map index data never overlap and allows complete
access to all available tile space.
-jason

www.thepernproject.com


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

--- In gbadev@y..., "Willem Kokke" <wkokke@g...> wrote:
> With a period of 64 it takes 0.001003265380859375 seconds to make
the
> timer reach 263

well, that is exactly the plan. i wanted to implement a timer that is
accurate to 1/1000 s...

> One other point you should check, is wheter that define use a
volatile
> pointer, else the compiler will optimise it away
> But I think that's not the problem
>

it was indeed the problem that the pointer was not defined as
volatile...
actually, i recently changed from basic to c++ and there are many
things about c i don't know yet (for example that pointers which are
not volatile will be "rationalized" away...)
thank you guys...

roman

Hi,

I'm trying to call Thumb ROM code from an ARM IWRAM routine.
Unfortunately, I get error messages like this:

Fastcode.text.iwram.o(.iwram+0xbd4): relocation truncated to fit:
R_ARM_PC24 CreateObject

To fix this I believe I need to mark the original declaration of
CreateObject() as being in ROM as follows:

#define CODE_IN_ROM __attribute__ ((section (".text"), long_call))

OBJECT* CreateObject( const STRUCTURE* StructureRef, int x, int y, int
rxy ) CODE_IN_ROM;

However, it won't compile unless I also change the definition of the
original function as follows:

CODE_IN_ROM OBJECT* CreateObject( const STRUCTURE* StructureRef, int x,
int y, int rxy )
{
    // code here
}

This compiles and links ok, but the CreateObject() function no longer
works even though there weren't any problems before. Any ideas?

Thanks for your help,
James.
--
     /\  apex                                 James Daniels
    //\\  designs            james.daniels@...
   //__\\                       http://www.apex-designs.net

Normally there is no need to check the timer yourself..

The normal timer usage is this:

Set the correct period to use..  (every 1, 64, 256 or 1024 clocks)
Set the start value by writing to TMxCNT_L, this is the value at which
the timer will start every time it overflows or gets started..  Standard
this is 0
Set the interrupt and enable it
Start the timer..

Now the timer will start at the start value, get increased every period
of clocks, and on overflow the interrupt will get called, in which you
do the handling..

http://www.suddenpresence.com/sgade/ has a nice implementation, you
might wanna look for sourcecode there


Now to your problem:

while(REG_TM3D < 263)

Depending on the period you chose, this situation will occur fast to
VERY fast. That's why you probably don't even notice it waiting..

With a period of 1 it takes 0.000015676021575927734375 seconds to make
the timer reach 263
With a period of 64 it takes 0.001003265380859375 seconds to make the
timer reach 263
With a period of 256 it takes 0.0040130615234375 seconds to make the
timer reach 263
With a period of 1024 it takes 0.01605224609375 seconds to make the
timer reach 263

So in the best case, it will only be a wait of 1/100ths of a second,
hardly noticable most of the times..


If you put in a WaitVblank(), after each check it waits an entire frame
before it checks again, obviously this will lead to incorrect results..


One other point you should check, is wheter that define use a volatile
pointer, else the compiler will optimise it away
But I think that's not the problem


Hope that helps,
Willem





> -----Original Message-----
> From: Roman Schaub [mailto:roman@...]
> Sent: Thursday, September 05, 2002 16:19 PM
> To: gbadev@yahoogroups.com
> Subject: [gbadev] timer-problems
>
>
> hello there..
>
> since i need a timer in my game, i tried to create a function
> which uses one of the internal timer registers (obviously).
> the problem i encountered was:
>
> if i create a while-loop and check the value of the counter,
> it never stops! (means: the cpu doesn't check the value of
> the counter, but if i insert something like
> "WaitforVBlank()" into the while-loop, the counter works
> correctly (but significantly slower...).
>
> while(REG_TM3D < 263){}         //doesn't work
>
> while(REG_TM3D < 263){WaitVblank();}         //works....
>
> i also tried to enable the interrupt-on-overflow...didn't
> work either...
>
> it just seems that counting occupies the cpu to 100% so he
> doesn't have the time anymore to check if the
> abort-conditions have already reached... i really don't have
> a clue how to fix that.
>
> cheers
>
> roman

> while(REG_TM3D < 263){}         //doesn't work
>
> while(REG_TM3D < 263){WaitVblank();}         //works....

How is 'REG_TMD3D' defined?  Is it volatile?

Waiting for Vblank within the while loop puts the CPU on halt until a Vblank
interrupt fires, so that happens at roughly 60Hz... That's probably not what
you want when you use a timer, because you won't be able to test the timer's
value while the CPU is on halt (you will only peek once a frame so the timer
will probably loop a few times in the meantime, depending on timer
frequency).

Jan-Lieuwe

You're sure you have declared REG_TM3D to be volatile right? Otherwise the
value will likely be cached, thus changes in it will be unnoticed?

Just something obvious I thought of straight away, cause I have noticed a
gba.h floating around that didn't declare any registers to be volatile.

Greg

At 10:19 PM 5/09/2002, you wrote:
>hello there..
>
>since i need a timer in my game, i tried to create a function which uses
>one of the internal timer registers (obviously).
>the problem i encountered was:
>
>if i create a while-loop and check the value of the counter, it never
>stops! (means: the cpu doesn't check the value of the counter, but if i
>insert something like
>"WaitforVBlank()" into the while-loop, the counter works correctly (but
>significantly slower...).
>
>while(REG_TM3D < 263){}         //doesn't work
>
>while(REG_TM3D < 263){WaitVblank();}         //works....
>
>i also tried to enable the interrupt-on-overflow...didn't work either...
>
>it just seems that counting occupies the cpu to 100% so he doesn't have
>the time anymore to check if the abort-conditions have already reached...
>i really don't have a clue how to fix that.
>
>cheers
>
>roman
>
>
>[Non-text portions of this message have been removed]
>
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

----
Wogan (wogan@...)

hello there..

since i need a timer in my game, i tried to create a function which uses one of
the internal timer registers (obviously).
the problem i encountered was:

if i create a while-loop and check the value of the counter, it never stops!
(means: the cpu doesn't check the value of the counter, but if i insert
something like
"WaitforVBlank()" into the while-loop, the counter works correctly (but
significantly slower...).

while(REG_TM3D < 263){}         //doesn't work

while(REG_TM3D < 263){WaitVblank();}         //works....

i also tried to enable the interrupt-on-overflow...didn't work either...

it just seems that counting occupies the cpu to 100% so he doesn't have the time
anymore to check if the abort-conditions have already reached...
i really don't have a clue how to fix that.

cheers

roman


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

yeah, got a bit confused as to what he was asking about there! the example I
was giving was for a 360 * 240 map which was using 1350 unique 16 colour
chars (it was quantised down from the originally hand painted 32bit image)
so there was the need to set different layers to different char banks so we
could display it all :)

still - quite a nice feature and I do still wonder if you can change a
layers char bank offset in hblank.. ill do some investigation when I get a
bit of time :)

ninge
   -----Original Message-----
   From: yerricde [mailto:d_yerrick@...]
   Sent: 04 September 2002 18:23
   To: gbadev@yahoogroups.com
   Subject: [gbadev] Re: how to use 2 char block on the same bg?!?


   --- In gbadev@y..., "ninge" <ninge@a...> wrote:
   > you would need to use a hblank to change the char base block
   > value at the correct position down the screen.

   No, that was the NES, with a hard limit of 256 different tile
   indices.  Some games stretched their title screens over four
   4 KB tile banks to cover all 960 tiles of the NES's display.
   Videomation, the NES precursor to Mario Paint, did the same
   thing.  So did Qix.

   The Super NES and GBA, on the other hand, can use tiles from
   multiple 16 KB banks on one non-affine tile map because the
   tile indexes are 10 bits as opposed to 8 bits.  Think of the
   tile data bank setting in BGxCNT as specifying a "starting
   address" for tile data.  For instance, if you set the base
   address to 0 and use 16-color tiles, you can access tiles
   from the beginning of bank 0 (index 0) to the end of bank 1
   (index 1023).  With 256 color tiles, you can go all the way
   from the beginning of bank 0 (index 0) to the end of bank 3
   (index 1023); however, in that case, you'll need to overlap
   your map with your tile data.

   Real 16-color example:  Tetanus On Drugs for GBA.  It stores
   the playfield background in 16-color tiles from 0x0600b000 to
   0x0600ffff. Then it sets the base address to 2 (0x06008000)
   and uses indices 384 to 983.

   Real 256-color example: Farbrausch's "fr018: aGb" demo.
   Many of its phases fill the screen with a 256-color APA tile
   map that uses indices 0 to 599, spanning 38 KB of VRAM.  The
   demo does this primarily so it can layer other backgrounds
   on top or below (such as the second scene with water ripples
   on top of a Hyperzone style background).

   However, if you're using affine backgrounds, you can't use
   more than 256 indices.  If you're scaling and not rotating,
   however, you can possibly use the NES style hblank bank-
   switching technique.

   --
   Damian



         Yahoo! Groups Sponsor
               ADVERTISEMENT



   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
         intY has scanned this email for all known viruses (www.inty.com)


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

--- In gbadev@y..., "ninge" <ninge@a...> wrote:
> you would need to use a hblank to change the char base block
> value at the correct position down the screen.

No, that was the NES, with a hard limit of 256 different tile
indices.  Some games stretched their title screens over four
4 KB tile banks to cover all 960 tiles of the NES's display.
Videomation, the NES precursor to Mario Paint, did the same
thing.  So did Qix.

The Super NES and GBA, on the other hand, can use tiles from
multiple 16 KB banks on one non-affine tile map because the
tile indexes are 10 bits as opposed to 8 bits.  Think of the
tile data bank setting in BGxCNT as specifying a "starting
address" for tile data.  For instance, if you set the base
address to 0 and use 16-color tiles, you can access tiles
from the beginning of bank 0 (index 0) to the end of bank 1
(index 1023).  With 256 color tiles, you can go all the way
from the beginning of bank 0 (index 0) to the end of bank 3
(index 1023); however, in that case, you'll need to overlap
your map with your tile data.

Real 16-color example:  Tetanus On Drugs for GBA.  It stores
the playfield background in 16-color tiles from 0x0600b000 to
0x0600ffff. Then it sets the base address to 2 (0x06008000)
and uses indices 384 to 983.

Real 256-color example: Farbrausch's "fr018: aGb" demo.
Many of its phases fill the screen with a 256-color APA tile
map that uses indices 0 to 599, spanning 38 KB of VRAM.  The
demo does this primarily so it can layer other backgrounds
on top or below (such as the second scene with water ripples
on top of a Hyperzone style background).

However, if you're using affine backgrounds, you can't use
more than 256 indices.  If you're scaling and not rotating,
however, you can possibly use the NES style hblank bank-
switching technique.

--
Damian

you would need to use a hblank to change the char base block value at the
correct position down the screen. either that or use two layers and have the
first set to the first char block (showing the top half) and the second set
to display the second char block (showing the bottom half)

weve used the second method in our current game where we have a full screen
scrolling map with zero repeated chars but don't have enough room to store
it as a 256 colour image and scroll it in mode 4. Instead we used mode 0 and
had two char blocks and split the screen over two layers... not sure if
using hblank to change it would work but im guessing you don't have a free
layer so I think that's the only thing you can try :)

ninge
   -----Original Message-----
   From: Marco [mailto:xinn@...]
   Sent: 04 September 2002 15:03
   To: gbadev
   Subject: [gbadev] how to use 2 char block on the same bg?!?


   I want to set up bg 2 in mode 1 to create a scrollable background. The bg
is
   made from a complete image so there
   is no tile repetion and it is divided it in tiles only to be usable it in
   this mode. The bg is also horizontally wrappale.
   The background image is 256x120 so with 256 unique tiles I can only cover
an
   area of 256x64 pixels, 32x8tiles.

   But I've found a rom that use 2 different char base blocks (block 2 and 3)
   on the same bg (well int the bg register
   only block 3 is addressed... but the final result requires the tile data
   from both) and I've no idea how to setup a
   thing like that (and from the documentation I've read a thing like that is
   not possible).

   I've dumped the the screen base block used by bg 2 (7). The first part
look
   like that

   0x6003800: 00 01 02 ........................ 0F
   0x6003810: 10 11 12 ........................ 1F
   and so on..
   0x60038F0: F0 F1 F2 ........................ FF

   and that's clear beacuse it's addressing every tile in a linear way.
   The second part is equal to the first but reach only the line in D0 D1 ...
   then turn to FF FF FF..  till address 0x6003c00

   What's strange is that the first part address tiles in char block 2 and
the
   second in char block 3!

   Please, help!!






         Yahoo! Groups Sponsor
               ADVERTISEMENT




   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
         intY has scanned this email for all known viruses (www.inty.com)


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

--- In gbadev@y..., "Marco" <xinn@l...> wrote:
> But I've found a rom that use 2 different char base blocks
> (block 2 and 3)

You can fit 256 8-bit tiles or 512 4-bit tiles into a 16 KB bank.
If you have more than 256 tiles, just use tile numbers greater
than 255.  If a tile number overflows e.g. tile bank 2, it will
spill into bank 3.  (This has worked since the Super NES.)
Tetanus On Drugs for GBA uses this to display its wallpaper.

--
Damian

I want to set up bg 2 in mode 1 to create a scrollable background. The bg is
made from a complete image so there
is no tile repetion and it is divided it in tiles only to be usable it in
this mode. The bg is also horizontally wrappale.
The background image is 256x120 so with 256 unique tiles I can only cover an
area of 256x64 pixels, 32x8tiles.

But I've found a rom that use 2 different char base blocks (block 2 and 3)
on the same bg (well int the bg register
only block 3 is addressed... but the final result requires the tile data
from both) and I've no idea how to setup a
thing like that (and from the documentation I've read a thing like that is
not possible).

I've dumped the the screen base block used by bg 2 (7). The first part look
like that

0x6003800: 00 01 02 ........................ 0F
0x6003810: 10 11 12 ........................ 1F
and so on..
0x60038F0: F0 F1 F2 ........................ FF

and that's clear beacuse it's addressing every tile in a linear way.
The second part is equal to the first but reach only the line in D0 D1 ...
then turn to FF FF FF..  till address 0x6003c00

What's strange is that the first part address tiles in char block 2 and the
second in char block 3!

Please, help!!

--- In gbadev@y..., "Mike Wynn" <mike.wynn@L...> wrote:
> I have a very simple test program, that has 2 backgrounds and two
sprites
> but it does not work on any hardware, but runs fine on vba/ba
>
> the setup is simple, one bg(0) priority 3, bg(1) prio 2
> the sprites (OAM entryies 0,1) are such that 0 is a charactor, and
1 is the
> outline.
> initially oam[0] prio is 3 and oam[1] is 2;
>
> depending on if my code thinks the charactor is "obscured" it
changes the
> priority of oam[0]
> to be either 3 or 2, thus allowing bg(1) to either under or over
the char,
> but at all times the outline of the char is visible.

So if I understand this correctly, the order of things is like this
(priorities in parenthesis):

Top
oam1 (2)
bg1 (2)
oam0 (3)
bg0 (3)

but occasionally you can do this to show oam0 above bg1 and above
oam1:

Top
oam0 (2)
oam1 (2)
bg1 (2)
bg0 (3)


>
> this works fine on all the emulators I've tried, but up the
hardware, bg(1)
> is always under the charactor.
>
> I did see the same problem occur some times in my "torn desktop"
demo and in
> both it only occurs on
> real hardware, is there more to obj/bg priorites than meet the eye ?
>

I have encountered a similar problem, I think. If your sprites are
ovelapping (at the same x,y coords) then I definitely have
encountered this "gotcha". This is the explanation of the "feature"
as I see it:

On hardware, if there are sprites overlapping, and a sprite that
should be behind another due to natural z ordering in the sprite list
is actually in front due to priority ordering (i.e. it has a larger
spriteID, but the sprite with lower sprite ID has lower priority),
then the sprite that has the lower ID will be drawn to the same
priority as the one "on top" due to natural sprite z ordering. This
results in the BG ordering being screwed, because a sprite has been
given a higher priority than you were expecting...

It is clearer with a diagram, the first list above would actually
look like this on hardware:

Top
oam1 (2)
oam0 (3) <- drawn as if it has priority 2
bg1 (2)
bg0 (3)


The fix I did was sort for z ordering so that if a sprite of lower ID
has a priority value greater than one higher in the sprite list (i.e.
should be behind the higher one) and they overlap, then I swap the
OAM values (I swap sprite attrib 2 of the troublesome sprites).

Solution: Try swapping over your sprites 0 and 1 and it should fix
the problem, as you aren't going "against" sprite z ordering so much.

Seems a bit strange really - the only explanation I can think of is
that Nintendo intended Sprite Priority to be used relative to the
backgrounds only, not relative to other sprites, so you need to
carefully manage where abouts you put them in the sprite list and use
that as your sprite-to-sprite priority.

> real hardware, is there more to obj/bg priorites than meet the eye ?

There's a situation where you need to sort your sprites according to their
priorities IE pri 0 then pri 1 etc.

You've just encountered it.

Least I'd assume that's what's going on :)


Kriss

I have a very simple test program, that has 2 backgrounds and two sprites
but it does not work on any hardware, but runs fine on vba/ba

the setup is simple, one bg(0) priority 3, bg(1) prio 2
the sprites (OAM entryies 0,1) are such that 0 is a charactor, and 1 is the
outline.
initially oam[0] prio is 3 and oam[1] is 2;

depending on if my code thinks the charactor is "obscured" it changes the
priority of oam[0]
to be either 3 or 2, thus allowing bg(1) to either under or over the char,
but at all times the outline of the char is visible.

this works fine on all the emulators I've tried, but up the hardware, bg(1)
is always under the charactor.

I did see the same problem occur some times in my "torn desktop" demo and in
both it only occurs on
real hardware, is there more to obj/bg priorites than meet the eye ?

Mike.

At 10:27 AM 8/25/2002, nei_mod wrote:
>- Sending multiboot images to GBA
>- Displaying GBA memory data on PC screen
>- Dumping GBA memory to a file on harddisk
>- Saving a snapshot of the GBA VRAM to a .bmp (currently only works
>for tilemodes)
>- Modifying GBA memory
>
>In short, the only thing you need for debugging!

Great!  I've really gotten tired of having to debug my
C++ template classes on a PC.  Now I can debug them...
in assembly language?  :-}

Cheers,
-Pete

At 07:53 PM 8/23/2002, John Seghers wrote:
>GCC hosted on Win32 is a "console" application.  Its input and output are all
>text and file based. It is not interactive.
>As for command-line driven tools....

Visual Studio .NET stores its IDE project files in XML.  This means that
it's trivial (with the right scripting language) to have a script construct
the GNU makefile when you press F7.  ;-)

Cheers,
-Pete