In message <425134868.20010731173523@...>
           Vitaly Vidmirov <front@...> wrote:

> Hi Dennis!
>
> DR> Yes, that would indeed be better, i of course meant the highest played
> DR> rate... I guess, 22khz should be ok, but it seems that many commercial
> DR> games play there music at a much lower rate... (Which is something I
>
> Although i don't have a hardware, i think the ideal frequencies
> should be 16384-24576-32768-49152-65536 khz ;)
> This like "good" PC soundcards. They all use PWM DACs
> with fixed frequency (48khz). But we have more choice ;)

I'm not sure, whether 24576 and 49152 are really ideal, i think that
21845 (=65536/3) is, though.
I thought that it is best to have pwm_rate/sample_rate=integer.

> DR> hope will change in the future, as it is possible to play 8 channels
> DR> at 22khz using less than 20% processor time, which should be good enough
> DR> for nearly every game...)
>
> it could be faster
> say, 10-12 channels @ 22khz

Might be, i have so far only written a .mod player which plays 4 channels
(22khz) using 7% processor time, but it didn't feature free stereo
positions which i'd like to implement in my next player. The "8 chns in
<20%" is just an estimation, it might be slightly faster, but i don't
think you'll get 12 chns with free stereo (you didn't say anything about
stereo, of course...)

--
exoticorn/icebird

gameboyland.com wants to host homebrew GBA demos & games.
They want their site hits back or something.
So mailto:webmaster@... and give them ur URL or something.

D.F.


  -----Original Message-----
From: Webmaster [mailto:webmaster@...]
...
Subject: Legal roms, demos...

.... [Snip] .....

I would be very thankful if you could give me some help. My site,
gameboyland.com, was once the worlds largest GB Roms site on the
internet, until  I took the roms off. We are coming back, but we are now
only interested in homebrew, GBA/GBC/GB roms. We bring in quite a few
hits a day, it used to be 1500. If you have any friends who have roms
that would like to be public, i would gladly host them, as im now trying
to build the largest LEGAL roms site on the internet. If you could
contact them, or contact me, with any information on people i could
e-mail for their legal roms, please do so.
Thank you very much,


Matt Campbell
http://www.gameboyland.com
http://www.dreamcast.ca

> Yeah I figured as much but it looks kinda weird... What happens
> when you need
> to play a sample twice as fast?
> That wouldn't work would it?
>
> The carry bit is just one bit, so you can't add two with it can you?

Maybe some of the other guys have answared this, but you add with carry, not
just carry for the high fraction. It could look something like this:

This is not ARM or THUMB... it's eh.. an attempt to do something
understandable.

u16 nLow
u16 nHigh
u16 nLowAdd
u16 nHighAdd

add nLow,  nLowAdd (Carry is set if nLow overflows.)
adc nHigh, nHighAdd (Add nHighAdd AND the carry to nHigh.)

This way you can have the samples playing much more than double as fast or
half as fast as the normal samplerate of the sample.

Sorry, if I'm repeating something someone has already said.

- Tom

> Thats what confused me... correct me if I am wrong though!
>
> Paul.
>   ----- Original Message -----
>   From: James Boulton
>   To: gbadev@yahoogroups.com
>   Sent: Tuesday, July 31, 2001 3:39 AM
>   Subject: Re: SV: [gbadev] Protracker
>
>
>   > I am a little confused how the fraction steps work...
>
>   Works by overflow and add carry for the fractional part by the
> look of it.
>   Very simple and quick -- although, I have used a more compact
> method in my
>   mixer... :>
>
>   --Jim
>
>
>
>
>
>         Yahoo! Groups Sponsor
>               ADVERTISEMENT
>
>
>
>
>   list rules: http://www.gbadev.org/rules.txt
>   unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>
>   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>
>
> [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,

On Tue, 31 Jul 2001, Marco Iannaccone wrote:

> I'd like to buy a programmable card (and the programmer) for GBA. On
> lik-Sang I noticed Flash Advance 64Mb Ready to go Set. Is it good? I intend
> to use it with Windows 2000. Is 64 Mb enough, or whould it be better to buy
> the 128 Mb version?

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 ?

> How long does it take a package from Lik-Sang to arrive (I'm in Italy)? And
> how much will it cost for sending the pack to Italy?

If payment can be completed to HK, 3 or 4 days (I'm in Switzerland)

Stephane Magnenat

Hello Dan,

Tuesday, July 31, 2001, 6:46:11 AM, you wrote:

DP> On Jul 30, groepaz wrote:

>> theres a bug in gcc .... you need to call the function in wram through a
>> function-pointer or gcc will screw up the adress under certain
>> circumstances.

DP> No man, we had this discussion earlier! There aren't any bugs in GCC,
DP> your code is just too complex for it. =P ;-)

hehehe lol ;=)

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

Hi Dennis!

DR> Yes, that would indeed be better, i of course meant the highest played
DR> rate... I guess, 22khz should be ok, but it seems that many commercial
DR> games play there music at a much lower rate... (Which is something I

Although i don't have a hardware, i think the ideal frequencies
should be 16384-24576-32768-49152-65536 khz ;)
This like "good" PC soundcards. They all use PWM DACs
with fixed frequency (48khz). But we have more choice ;)

DR> hope will change in the future, as it is possible to play 8 channels
DR> at 22khz using less than 20% processor time, which should be good enough
DR> for nearly every game...)

it could be faster
say, 10-12 channels @ 22khz

[ http://vvid.chat.ru ]

Hi All,

  Keep in mind that, AFAIK, there are 3 versions of the Visoly
(for lack of a better name) 64M flash cart:

  64M Large / 64M Small / Turbo 64M Small

  For technical differences between the regular and "turbo"
series check the mailing list archives for my post on this about
a week ago.

  The turbo carts are unique in that they have a black label instead
of a blue label.

  64M/128M Small Photos:
     http://www.lik-sang.com/catalog/news.php?artc=178

  Turbo 64M/128M Small Photos:
     http://202.60.224.104/store.asp

  Jeff

On boot, just as you check 'a' to be in a gbc, you check 'b'.

GBC: b=0
GBA: b=1

People have mentioned checking bit 0 of 'b' only, for future
compatability, but I doubt that will be easy to enforce.

--- In gbadev@y..., "Dennis Munsie" <munsied@m...> wrote:
> Hello everyone,
>
> A bit of a topic switch (not much of one, mind you.. :)
>
> I was reading in one of the game mags at the supermarket yesterday
(can't
> remember which one, sorry!) that the new Zelda carts for the GBC
have areas
> that can only be reached when played on a GBA.  So, that brings me
to my
> question...  how do you detect that you are on a GBA from a GBC
game?
>
> thanks!
> dennis

Hello everyone,

A bit of a topic switch (not much of one, mind you.. :)

I was reading in one of the game mags at the supermarket yesterday (can't
remember which one, sorry!) that the new Zelda carts for the GBC have areas
that can only be reached when played on a GBA.  So, that brings me to my
question...  how do you detect that you are on a GBA from a GBC game?

thanks!
dennis

The player is going at around 15000hz at the moment...

It wont go any faster cos its too slow as its written in C and
runs from rom.

Now that I understand how this fraction thing works I will try
my hand at a little assembler....

Thanks for all the info guys...

I will let you know how I get on.

Paul.
   ----- Original Message -----
   From: Dave Murphy
   To: gbadev@yahoogroups.com
   Sent: Tuesday, July 31, 2001 4:59 AM
   Subject: RE: SV: [gbadev] Protracker




   > -----Original Message-----
   > From: Dennis Ranke [mailto:exoticorn@...]

   >
   > > you don't ever play a sample twice as fast. Someone will no
   > doubt tell me of
   > > some case I've forgotten but ... the tuning tables in
   > Protracker etc were
   > > designed so the samples were always pitched down. Thinking
   > about that for a

   > This is not exactly correct, considering the nature of the
   > original .mod
   > players on the amiga, as they didn't do any software mixing but used
   > the four hardware channels of the paula chip that could work at
   > a variable sampling rate quite similar to the two channels of the
   > gba...

   & there's the case I'd forgotten - the original hw that everyone has been
   emulating  :o) I do, of course, refer to the software mixing versions that
   proliferated on ST and the odd console or two.

   > > bit leads to some interesting optimizations for bus
   > bandwidth under certain
   > > conditions.
   > >
   > > ;o)
   >
   > This, however, is right when your players samplerate is at
   > least as high
   > as the highest pitch of any played sample. In this case, copying the
   > part of the sample that is to be mixed into internal ram will offer
   > some speed increase, with the downside of using more of the valuable
   > intram...

   and I'd really like to hope your sample rate is way higher than the highest
   pitch of any played sample ;)

   sorry couldn't resist ...


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


         Yahoo! Groups Sponsor
               ADVERTISEMENT




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



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



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

> you don't ever play a sample twice as fast. Someone will no doubt tell me
of

Um, that means you'd only ever be able to play at middle c and below! :)

Normal mod samples are at 12-somethingKHZ and at middle C as I remember.
They definitely get played faster than the original sampling rate.

Dont know if protracker is different to the normal mod stuff???

--Jim

Hi,

120Hz explains grey perfectly... in such case the display would show
both white and black lines, changing 120 times per second, what makes
perfect grey. (i.e. it could show all lines in 60Hz, and that behaviour may
look like hw lines blending)

  But could the display run at 120Hz ? How would you than sync it with
hblank things ?? It doens't make sense unless some sophisticated buffering
scheme for full screen is used. I mean, you start "showing" frame in SW
point of view (doing first mischief things in hblank like changing sprites,
etc...) ... you get into HALF of screen .... THAN could HW start to
draw every odd line, and it will show the bottom line just when you
are FINISHING drawing from SW point of view, and while you
are beginning the next half of frame, it would must to draw the even
lines.
  So it would need to buffer all your VRAM data, all your hblank changes,
etc.... does it make sense ? Not for me, so I don't believe it's running
120Hz.
  Could it be done in other way ? I really don't see it, I actually think,
that
I can "prove", that this or some similar is the only way to do it.

  On the other hand, how could be interlace not synced with the sw ?
If you are getting a stable grey color from black-white lines pattern,
than the out-of-sync method of interlace must be quite "stable" or
"synced" to provide you with stable grey.
  I actually couldn't quite imagine, how that could work. Sounds to me like
the LCD is so slow, that black/white changing at 10-15FPS would still lead
to grey (doesn't look very real to me, but it may turn to be true, LCD is
quite slow after all), or the interlace does use some other, but perfectly
synced pattern, like even-odd-even-odd line, or who knows what...
(in such case the speeding of engine by drawing that pattern is possible)
  The hw blending would explain it easily, but once more you would need
quite sophisticated HW, so it doesn't make sense too.

  And than there's that last thing, that with LCD even som quite unsynced
interlace does look good ... something I don't personaly believe to, but
may be true. :))

  Just wanted to tell you, that 120Hz is nonsense, if that's true, than I
definitely want to know, how it could be done, because my mind's
getting more closed every year, and I need *SUCH* fresh ideas. :)))
  The rest of mail is big *IMHO* ... anybody has some better
explanation/ideas, how's working that thing?

                   PED - Peter Helcmanovsky - wishing to have 48h days
             Braniskova 7 Kosice 04001 Slovakia phone: +421 55 6259058
     (_               -- actually in Brno, so don't look after me --
   "~/\~"       -=- deRATized  RAT -=-  Being beyond Yer imagination  -=-
   ,_oo_,      Illusion softworks: http://www.hidden-and-dangerous.com
       `'          7 GODS demo group WWW pages: http://7gods.sk

On Jul 31, N.W. wrote:

> right from my makefile (which is ripped from someone else's makefile)

Hmm... that looks familiar ;-)

> Then I just include "arm_code.h" into my main project, and load the
> contents into sound rom.
>
> So I imagine the same would be done with the GBA, except specify
> 0x3000000 as the -Ttext value.
>
> The armbase.o contains the startup code, taking the place of crt0.o,
> and I have no special linker script.

The problem with that method (if I understand you correctly) is that you
can't reference data between segments of your program, e.g., a segment
running in ROM wouldn't be able to interact with a segment running in
WRAM, unless you set up absolute addressed interaction buffers.

On Jul 30, groepaz wrote:

> theres a bug in gcc .... you need to call the function in wram through a
> function-pointer or gcc will screw up the adress under certain
> circumstances.

No man, we had this discussion earlier! There aren't any bugs in GCC,
your code is just too complex for it. =P ;-)

Hi Paul!

PC> Ooo... thats a tight loop!
PC> I am a little confused how the fraction steps work...
PC> Could you explain this for me please?

precalculate a reciprocal at first

recip = 0xffffffff / mix_freq;


;r0 = frequency in hz
;r1 = recip

         umull   r4,r5,r1,r0

;r4 = fractional part of (frequency/mix_freq)
;r5 = integer part ...

just 3 cycles in this order (frequency is the last operand)
place it somewhere before loop

that's all ;)

[ http://vvid.chat.ru ]

After at last picking up a machine with a bit more power (P266), I've
decided to have a go at porting the demo code running on my own GBA
environment over to the emulators and eventually the real GBA when I
get my hands on the cash. I know the P266 will still not do justice,
but at least I can get an idea of how legal my demo code is.

My apologies if this question has an obvious answer, but where can
the pre-built GNU Binutils for Win32 be downloaded from? For the life
of me, I can't find a site hosting them. I downloaded GCC (3.0)
sometime back, but only now have started to look at it in any detail.
The first thing I noticed was that there was no MAKE util, so I'm
using the MAKE util I used when doing PS1 deving. Currently, I've
managed to produce and ELF file, but if my understanding is correct I
must use OBJCOPY to generate a BIN file for the GBA/Emulators.

There's some good topics getting flung around the mailing list these
days, not too much chaff and the idea of a non-official SDK from
Jason Wilkins is a relief especially with the thought of tackling the
linker scripts.

Thanks Folks,

Niall

--- In gbadev@y..., "Marco Iannaccone" <marciann@t...> wrote:
> > Anyway, a least some notes on how to use the various tools, on
how the
> > linker script works, and so on, would be nice...
> And about crt0 and about general things, like the differences
between
> compiling for a pc and for a gba, like rom memory allocation,
etc....,
> too......
>
>
> Marco Iannaccone
> marciann@t...
> ICQ UIN: 18748121     MetalCoder
>
> "I am the way, I am the light, I am the dark inside the night,
> I hear your hopes, I feel your dreams, and in the dark I hear your
screams,
> don't turn away, just take my hand, and when you make your final
stand,
> I'll be right there, I'll never leave, all I ask of you, believe."
>           Jon Oliva - Savatage, Believe

feel free to correct me here but regardless of syncing don't you have to
contend with the persistence of the LCD display?

Having said that I do remember being able to see individual lines on GBC
sprites when I tried a similar trick.

> -----Original Message-----
> From: Jason Wilkins [mailto:fenix@...]
> Sent: 30 July 2001 20:28
> To: gbadev@yahoogroups.com
> Subject: Re: [gbadev] Taking advantage of interlacing..
>
>
> This brings up a question thats been bugging me.  The display is
> interlaced, but the vcount is progressive.  Also, everything about the
> display hardware interface seems to be progressive.  For
> example, hblank
> interupts and DMAs are progressive.  So, what is the relation
> ship between
> the interlacing and the vcount?
>
> I guess Groepez sort of answered it by saying that they are
> not in sync.
> Meaning that you can't say that on vcount = 0 through vcount
> = 79 that it
> has displayed every odd line, and that on vcount = 80 -
> vcount = 159 that
> it has displayed every even line.
>
> But, it seems to me they must be in some sort of sync.  If the display
> refreshes every other line every 60th of a second, and the display
> hardware does everyone scanline progressivly every 60th of a
> second and
> its keyed into the same clock, then why wouldn't they be in sync?
>
> I'm not making any assertions here, feel free to correct me
> anywhere I'm
> totally off base ^_^
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Small business owners...
> Tell us what you think!
> http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/cPRolB/TM
> --------------------------------------------------------------
> -------~->
>
> 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/
>
>


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

In message <FF6028679E32D511A8C400508BC87D1E5CFFB0@EXCHSRVR>
           Dave Murphy <davem@...> wrote:

> > This, however, is right when your players samplerate is at
> > least as high
> > as the highest pitch of any played sample. In this case, copying the
> > part of the sample that is to be mixed into internal ram will offer
> > some speed increase, with the downside of using more of the valuable
> > intram...
>
> and I'd really like to hope your sample rate is way higher than the highest
> pitch of any played sample ;)
>
> sorry couldn't resist ...

Heh, be welcome :)
Yes, that would indeed be better, i of course meant the highest played
rate... I guess, 22khz should be ok, but it seems that many commercial
games play there music at a much lower rate... (Which is something I
hope will change in the future, as it is possible to play 8 channels
at 22khz using less than 20% processor time, which should be good enough
for nearly every game...)

--
exoticorn/icebird

> -----Original Message-----
> From: Dennis Ranke [mailto:exoticorn@...]

>
> > you don't ever play a sample twice as fast. Someone will no
> doubt tell me of
> > some case I've forgotten but ... the tuning tables in
> Protracker etc were
> > designed so the samples were always pitched down. Thinking
> about that for a

> This is not exactly correct, considering the nature of the
> original .mod
> players on the amiga, as they didn't do any software mixing but used
> the four hardware channels of the paula chip that could work at
> a variable sampling rate quite similar to the two channels of the
> gba...

& there's the case I'd forgotten - the original hw that everyone has been
emulating  :o) I do, of course, refer to the software mixing versions that
proliferated on ST and the odd console or two.

> > bit leads to some interesting optimizations for bus
> bandwidth under certain
> > conditions.
> >
> > ;o)
>
> This, however, is right when your players samplerate is at
> least as high
> as the highest pitch of any played sample. In this case, copying the
> part of the sample that is to be mixed into internal ram will offer
> some speed increase, with the downside of using more of the valuable
> intram...

and I'd really like to hope your sample rate is way higher than the highest
pitch of any played sample ;)

sorry couldn't resist ...


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

In message <FF6028679E32D511A8C400508BC87D1E5CFF62@EXCHSRVR>
           Dave Murphy <davem@...> wrote:

> you don't ever play a sample twice as fast. Someone will no doubt tell me of
> some case I've forgotten but ... the tuning tables in Protracker etc were
> designed so the samples were always pitched down. Thinking about that for a

This is not exactly correct, considering the nature of the original .mod
players on the amiga, as they didn't do any software mixing but used
the four hardware channels of the paula chip that could work at
a variable sampling rate quite similar to the two channels of the
gba...

> bit leads to some interesting optimizations for bus bandwidth under certain
> conditions.
>
> ;o)

This, however, is right when your players samplerate is at least as high
as the highest pitch of any played sample. In this case, copying the
part of the sample that is to be mixed into internal ram will offer
some speed increase, with the downside of using more of the valuable
intram...

--
exoticorn/icebird

> The carry bit is just one bit, so you can't add two with it can you?
>
> Thats what confused me... correct me if I am wrong though!

The add with carry adds a register WITH the carry bit. Not JUST the carry
bit! The register being added contains the integer part of the fixed point
frequency / adder.

--Jim

you don't ever play a sample twice as fast. Someone will no doubt tell me of
some case I've forgotten but ... the tuning tables in Protracker etc were
designed so the samples were always pitched down. Thinking about that for a
bit leads to some interesting optimizations for bus bandwidth under certain
conditions.

;o)

> -----Original Message-----
> From: Paul Carter [mailto:paul.carter2@...]
> Sent: 31 July 2001 20:20
> To: gbadev@yahoogroups.com
> Subject: Re: SV: [gbadev] Protracker
>
>
> Yeah I figured as much but it looks kinda weird... What
> happens when you need
> to play a sample twice as fast?
>
> That wouldn't work would it?
>
> The carry bit is just one bit, so you can't add two with it can you?
>
> Thats what confused me... correct me if I am wrong though!
>
> Paul.
>   ----- Original Message -----
>   From: James Boulton
>   To: gbadev@yahoogroups.com
>   Sent: Tuesday, July 31, 2001 3:39 AM
>   Subject: Re: SV: [gbadev] Protracker
>
>
>   > I am a little confused how the fraction steps work...
>
>   Works by overflow and add carry for the fractional part by
> the look of it.
>   Very simple and quick -- although, I have used a more
> compact method in my
>   mixer... :>
>
>   --Jim
>
>
>
>
>
>         Yahoo! Groups Sponsor
>               ADVERTISEMENT
>
>
>
>
>   list rules: http://www.gbadev.org/rules.txt
>   unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>
>   Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service.
>
>
>
> [Non-text portions of this message have been removed]
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> The Nissan Sentra
> Everything but compact
> http://NissanDriven.com
> http://us.click.yahoo.com/3vsIKC/txlCAA/ySSFAA/cPRolB/TM
> --------------------------------------------------------------
> -------~->
>
> 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/



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

Yeah I figured as much but it looks kinda weird... What happens when you need
to play a sample twice as fast?

That wouldn't work would it?

The carry bit is just one bit, so you can't add two with it can you?

Thats what confused me... correct me if I am wrong though!

Paul.
   ----- Original Message -----
   From: James Boulton
   To: gbadev@yahoogroups.com
   Sent: Tuesday, July 31, 2001 3:39 AM
   Subject: Re: SV: [gbadev] Protracker


   > I am a little confused how the fraction steps work...

   Works by overflow and add carry for the fractional part by the look of it.
   Very simple and quick -- although, I have used a more compact method in my
   mixer... :>

   --Jim





         Yahoo! Groups Sponsor
               ADVERTISEMENT




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



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



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

> I am a little confused how the fraction steps work...

Works by overflow and add carry for the fractional part by the look of it.
Very simple and quick -- although, I have used a more compact method in my
mixer... :>

--Jim

I'd like to buy a programmable card (and the programmer) for GBA. On
lik-Sang I noticed Flash Advance 64Mb Ready to go Set. Is it good? I intend
to use it with Windows 2000. Is 64 Mb enough, or whould it be better to buy
the 128 Mb version?

How long does it take a package from Lik-Sang to arrive (I'm in Italy)? And
how much will it cost for sending the pack to Italy?

Marco Iannaccone
marciann@...
ICQ UIN: 18748121     MetalCoder

"I am the way, I am the light, I am the dark inside the night,
I hear your hopes, I feel your dreams, and in the dark I hear your screams,
don't turn away, just take my hand, and when you make your final stand,
I'll be right there, I'll never leave, all I ask of you, believe."
           Jon Oliva - Savatage, Believe

Hi,

I have got a problem here and I don't know why but sval (char*) is empty after
executing the following code (compiled with ARM SDK). strlen and strncpy should
work fine but it
seems that the new operator does not work...

String::String(const char* bb) {
	 u32 l = strlen(bb);
	 sval = new char[l + 1];
	 strncpy(sval, bb, l);
	 sval[l] = '\0';
}

Can anyone help me with that?

Thanks,

Thomas Immich

Hello Dennis,

Tuesday, July 31, 2001, 11:30:42 AM, you wrote:

DR> I have done this in my kunterbunt demo, with about the same result as you,
DR> ie. better than 30fps but worse than 60.
>>From what i have seen so far, it looks as if all 160 lines are actually
DR> rendered each frame, only half of them with less intensity. For example
DR> take a look at the map and the shadows in fzero, if you have that game.
DR> They seem to be made transperent by switching them on/off each frame
DR> and you'll see that every 2nd line is a bit lighter, but still
DR> visible...
DR> I can only speculate why it is done this way, maybe they couldn't get
DR> lc displays that could properly support a real 60hz refresh or sth...


there was a detailed explenation of that stuff in earlier gbC docs if
i remember right...maybe also pan-docs includes it.

basically think of it working like this (and now comes a technically
very wrong description ;D) ...

the cpu renders to vram - this operation is perfectly in sync. now
"part one" of the display-circuit takes gfx-information from vram and
oam etc end renders the final image to be displayed to an internal
buffer. at this point still everything is in sync, the internal buffer
gets updates 60times a second. (if it wasnt none of the raster-based
fx would work) ... now "part two" of the display circuit uses the
contents of the internal buffer to drive the lcd-panel - THIS
operation is _NOT_ in sync with the rest (and it doesnt have to be),
incase of the gba it runs slightly faster than 60hz (same on gbc)

remember this is technically incorrect, but its still basically how
all/most lcd displays work internally.... you cant notice the effect
on more expensive panels 'coz their "part two" is running with a much
higher frequency.

however, i'd still like a hardware-register to read the current status
of the circuits "part two" but i doubt i'll find it =)

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

In message <D04CB855B82AC445B6FE0CA7FA936BC01711@...>
           "Thomas Nielsen [Liftoff]" <thomasn@...> wrote:

> I also tried arranging my engine for this princip. You get an
> interesting effect; in a lot of cases beter than 30fps - but not
> perfect.
>
> Has anyone else experimented, and maybe gotten better results than me?

I have done this in my kunterbunt demo, with about the same result as you,
ie. better than 30fps but worse than 60.
From what i have seen so far, it looks as if all 160 lines are actually
rendered each frame, only half of them with less intensity. For example
take a look at the map and the shadows in fzero, if you have that game.
They seem to be made transperent by switching them on/off each frame
and you'll see that every 2nd line is a bit lighter, but still
visible...
I can only speculate why it is done this way, maybe they couldn't get
lc displays that could properly support a real 60hz refresh or sth...

--
exoticorn/icebird

Sorry for the off topic post, but I received a bug report on GBDK from a
guy called Decimal, but he left a fake address as his return address.
Anyone know his current address?  Please reply off the list.

-- Michael

> I think he was refering to the idea that "declaring and defining
data on
> the same line should cause it to be store in ROM" is a correct idea.
> Since its not correct behavior you should find a way to fix it, not
work
> around it.

Agreed.  Though my first ambition was to get the damn thing working
<g>


> > Now this seems illogical, you are asking the guy to learn a fair
> > bit of assem and linker scripts just so that he can make a proper
> > ctr0 work correctly. For the majority of people the manual
solution
> > that I have presented here gets the job done with as little fuss
> > as possible.
>
> Workarounds are not "little fuss", they are extra fuss. Jeff and I
have
> just put together a linker script and crt0 which fixes these
problems and
> which behaves more like C/C++ should.  We shouldn't be working
around
> buggy tools (or worse yet, saying that thier bugs are the way
things are
> supposed to work), we should be fixing them.
>
> Anyway, I think a person who is doing GBA dev should learn at least
a
> little bit of assembly and esoteric things like linker scripts.
> Programmers are always better off knowing how their tools work.

I'm glad for the quick assistance that got me up and running.  This
is perfectly fine for someone who is just starting out and wants to
see the pretty background scroller work ;-)

However, I would like to see your little workaround to get correct
compiler behavior.  I suspect this problem is also to blame for the
static locals being allocated in ROM as well (which is VERY wrong
behavior no matter how you slice it).

I agree, anyone who wants to get into GBA development should at least
familiarize themselves with assembler.  I'm a master at 68k assembler
so ARM is not much of a stretch ;-)


Cheers!