Hi.  We're looking for interested coders to join us in
creating a game.  We have 2 pixel artists formerly of
the demo scene and we are serious about making a
commercial quality demo of a game.  Location in Europe
is a plus!



__________________________________________________
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com

Well, then, it's also completely within the scope of the GPL for their
customers to make available the source code to anyone else.  The point of
the GPL is to grant additional rights that you don't normally have.

I can see your point that legally, Nintendo only has to provide source to
those they provide a binary to.  In fact, I've seen that portion of the GPL
before.  But, at the same time, their customers are completely free to post
the source out to the Internet.

Now, Nintendo may be a bit pissed if this happens, but legally, they can't
do a thing.  Except send their lawyers in to make you have a really bad
day... hence, this would be something for someone with good lawyers to
handle, or the FSF.

Does anyone know the legalities of placing GPL code under a NDA?  The GPL
license specifically states that you can't take away rights granted by the
license.  And a NDA specifically removes rights.  It seems as there is a
conflict here, and though IANAL, it would seem that the original license
(GPL) would win here, and the NDA would not affect any GPL code.

dennis

PS, I also don't want to get into a license flame war -- but, I would like
to have the best damn version of gcc for the GBA that I can legally get my
hands on. :)

> On Monday 03 Dec 2001 9:30 pm, you wrote:
> > maybe someone should press a bit further into this lack of source/patch
> > availability with Nintendo... probally someone with a good lawyer
>
> If this is the case, stallman would have already been after them pretty
> heavily. Are we sure that what they supply is a modified version of gcc? And
> not just their own compiler? If it is, i hope one of the registered
> developers on this list will contact the FSF.

yes, the SNSys stuff is based on GCC and yes, the source is available to
their customers on request. 100% GPL legal and waterproof.

> i'm not really happy with the code generated by gcc3, it seems to be 25%
> slower when nintendo's official gcc 2.9..  disassembly looks pretty
> similar, but the register usage is more conservative. i believe nintendo
> and sn systems are tuning gcc to produce better arm code and making
> their own mods.. wouldn't it be a violation of GPL to keep these changes
> away of public? ;-)  just want to say it would be nice to see their
> compiler patches. even licensed devr's have access only to binaries ;(
>
> Dima

well, i am using gcc3 beta from SNSys and for me the produced code is
faster than the old 2.9x from them ...
and no, they are not violating the GPL. they only have to give the
sourcecode to people who got the binaries directly from them. the
GPL is pretty clear about this fact. and if you are using SNSys stuff,
just read the sources.txt file that comes with it before starting GPL
talk (well, maybe reading the GPL too would also help, heh)

cheers,
Markus

On 03 Dec 2001 16:30:52 -0500, Dennis Munsie wrote:
> maybe someone should press a bit further into this lack of source/patch
> availability with Nintendo... probally someone with a good lawyer


this someone would lose. check GPL before starting this kind of talk.
they ONLY have to make the sources available to their CUSTOMERS. you
didn't pay for the binaries, you don't get the source. as simple as
that. *deja-vu*

now please stop this GPL / OpenSource / Homer talk ... don't let this
nice list go the same way as the ps2dev list went with their pointless
GPL discussions ...

cheers,
Markus

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 03 Dec 2001 9:30 pm, you wrote:
> maybe someone should press a bit further into this lack of source/patch
> availability with Nintendo... probally someone with a good lawyer

If this is the case, stallman would have already been after them pretty
heavily. Are we sure that what they supply is a modified version of gcc? And
not just their own compiler? If it is, i hope one of the registered
developers on this list will contact the FSF.

- --
Tom "Tomahawk" Badran
Department of Computing, Imperial College
- -----------------------------------------------
PGP Key available from certserver.pgp.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8C/PgXCpWOla2mCcRAiT2AKCTwHiGUc3+t+7STY/G49PbC7RjGQCfUo0w
ZYhZw7Z4wpkd3sOeDWFla7I=
=zedQ
-----END PGP SIGNATURE-----

maybe someone should press a bit further into this lack of source/patch
availability with Nintendo... probally someone with a good lawyer

-----Original Message-----
From: Dima [mailto:dmitri.dev@...]
Sent: Monday, December 03, 2001 4:24 PM
To: gbadev@yahoogroups.com
Subject: RE: [gbadev] A bit of the old IN-OUT!!

i'm not really happy with the code generated by gcc3, it seems to be 25%
slower when nintendo's official gcc 2.9..  disassembly looks pretty
similar, but the register usage is more conservative. i believe nintendo
and sn systems are tuning gcc to produce better arm code and making
their own mods.. wouldn't it be a violation of GPL to keep these changes
away of public? ;-)  just want to say it would be nice to see their
compiler patches. even licensed devr's have access only to binaries ;(

Rafael Vuijk (aka Dark Fader) wrote:
>
> Can I also specify that a function should compile to ARM opcodes?
>
> D.F.

no i think it's not possible, but this would be really nice. afaik at
the moment u can only change the cpu target on per-file basis. put yr
arm code in a separate source file and compile it with -mcpu=arm7tdmi
-marm

starting with version 3, gcc is using the single compiler for arm and
thumb targets. i believe it's possible make a compiler mod with some
sort of a new #pragma which switches internal compiler flags to a
different target cpu within the same source file, but i didn't bother to
try it yet.. maybe somebody else got anough time to hack it in? ;-)

i'm not really happy with the code generated by gcc3, it seems to be 25%
slower when nintendo's official gcc 2.9..  disassembly looks pretty
similar, but the register usage is more conservative. i believe nintendo
and sn systems are tuning gcc to produce better arm code and making
their own mods.. wouldn't it be a violation of GPL to keep these changes
away of public? ;-)  just want to say it would be nice to see their
compiler patches. even licensed devr's have access only to binaries ;(

Dima

P.S. looking forward for finished SSA and dead code elimination support
in gcc 3.. both features are already implemented, but still experimental
and disabled by default. i was trying it with gcc 3.0.1, seems to
produce garbage code.. ;(

( for people wanting play with it: enable -fssa -fdce compiler switches.
)

--- In gbadev@y..., "Dave Carter" <david.carter@c...> wrote:
> REG_WIN0H = 0x1400 | 0x00DC;
> REG_WIN0V = 0x1400 | 0x008C;
> REG_WININ = 0x0000;
> REG_WINOUT = 0x0000 | 0x001F;
>
> SetMode(MODE_0 | OBJ_ENABLE | OBJ_MAP_1D | WIN1_ENABLE);

If you haven't already realized it before reading this message (or
didn't copy/paste your code and made a typo), you're setting the
coords for WIN0 and enabling WIN1. Other than that I can't find
anythign that should keep it from working.

hi dave!

i don't have the headers here at home but from what i can see i'd guess
you are setting up win0 flags _but_ you turn on win1 in the SetMode()
statement...
of course i could be all wrong, heh ... let's have a look at it tomorrow
at work ...

cheers,
Markus


On 03 Dec 2001 17:43:10 +0000, Dave Carter wrote:
> Hi all,
>
> I've read the recent messages about the window modes on the GBA from
> John Q and NetSlut, which gave me a great idea on what window modes
> can do and roughly how to use them. I've also looked through the
> section in the official docs about them, and I've got the specifics
> of what bits to set in the various registers. But somehow, I still
> can't get it to work at all!
>
> Here's my current test code (using most of devoto's header files):
>
> REG_WIN0H = 0x1400 | 0x00DC;
> REG_WIN0V = 0x1400 | 0x008C;
> REG_WININ = 0x0000;
> REG_WINOUT = 0x0000 | 0x001F;
>
> SetMode(MODE_0 | OBJ_ENABLE | OBJ_MAP_1D | WIN1_ENABLE);
>
> To the best of my knowledge, this should define a window 20 pixels in
> from the sides of the screen, and turn off everything inside that
> window, and turn on everything outside of it. What I actually get is
> everything on everywhere, which doesn't give me much to go on!
>
> One thing that did occur to me (although it's of the straw-grabbing
> variety of answers) was that maybe windows aren't available in the
> VGBA dos based emulator I'm using for testing? Bit of a long shot as
> it's been great for everything so far.
>
> Thanks for any help, or pointers to example programs!
>
> Dave

I'm not speaking from experience, but don't you use -mthumb for thumb code?
And, here's the part that I'm not sure of, but would it be -marm for ARM, or
does it just default to ARM?

These would be on the command line... I don't know if you can specify it
within a source file.

dennis

-----Original Message-----
From: Rafael Vuijk (aka Dark Fader) [mailto:darkfader@...]
Sent: Monday, December 03, 2001 12:37 PM
To: gbadev@yahoogroups.com
Subject: RE: [gbadev] A bit of the old IN-OUT!!


Can I also specify that a function should compile to ARM opcodes?

D.F.

Can I also specify that a function should compile to ARM opcodes?

D.F.


> ----- Original Message -----
> From: "Dima" <dmitri.dev@...>
> To: <gbadev@yahoogroups.com>
> Sent: Monday, December 03, 2001 9:16 AM
> Subject: RE: [gbadev] A bit of the old IN-OUT!!
>
>
> > just the same way :)
> >
> > class foo
> > {
> > public:
> > void fun(u32 a, u32 b) __attribute__((section(".iwram"),long_call));
> > };
> >


[cropped by mod]

Hi all,

I've read the recent messages about the window modes on the GBA from
John Q and NetSlut, which gave me a great idea on what window modes
can do and roughly how to use them. I've also looked through the
section in the official docs about them, and I've got the specifics
of what bits to set in the various registers. But somehow, I still
can't get it to work at all!

Here's my current test code (using most of devoto's header files):

REG_WIN0H = 0x1400 | 0x00DC;
REG_WIN0V = 0x1400 | 0x008C;
REG_WININ = 0x0000;
REG_WINOUT = 0x0000 | 0x001F;

SetMode(MODE_0 | OBJ_ENABLE | OBJ_MAP_1D | WIN1_ENABLE);

To the best of my knowledge, this should define a window 20 pixels in
from the sides of the screen, and turn off everything inside that
window, and turn on everything outside of it. What I actually get is
everything on everywhere, which doesn't give me much to go on!

One thing that did occur to me (although it's of the straw-grabbing
variety of answers) was that maybe windows aren't available in the
VGBA dos based emulator I'm using for testing? Bit of a long shot as
it's been great for everything so far.

Thanks for any help, or pointers to example programs!

Dave

owaincole@t... wrote:
> Hi, just wondered if you could clarify whether declaring the function
> as
>
> void fun(void) __attribute__((section(".iwram"),long_call));
>
> actually puts the function in iwram? Or do you need to do something
> else too (eg when you define it).
> All help much appreciated!
> Owain

right, i could be more precise... ;) i was assuming that people are
using devkitadvance gcc port whith jeff's linkscript and crt0.s and was
too lazy to write the details down.

the statement above is just telling compiler to assign the function code
to .iwram section and to assume that the function address is far away
and can't be reached by short calls (implies indirect calls by loading
the absolute 32bit address into register before calling it, samilar way
as c++ does when you are calling virtual methods.) if you are using
linkscript and crt file mentioned above, there is nothing more you have
todo. but.. just specifying the __attribute__ without telling to linker
what this is all about is of course not enough..

linker has to know where to put .iwram section actually, that's what the
linkscript is good for. for example, jeffs lnkscript has following
statement (i simplified it a bit):

   __iwram_start = 0x3000000; // VMA
   __iwram_lma = .;  // LMA
   .iwram __iwram_start: AT (__iwram_lma)
   {
     *(.iwram)
     . = ALIGN(4);
   } = 0xff
   __iwram_end = . ;

this tells linker to collect all .iwram code from your object files and
merge it into a single .iwram section of your output .elf file. the code
is placed at the first available address in ROM(!) (so called 'load
memory address') and labeled as __iwram_lma. this also tells linker that
the section starts at virtual address 0x3000000 (gba internal ram), this
means that all symbolic references to code and data in .iwram section
will be resolved as if the code were placed in internal ram. (for more
information on linkscripts see the linker documentation on gnu.org)

linker can not load your code into internal ram, this is a job of your
startup code (jeffs crt0.s implements this.) at startup, the crt
initialisation routine copies the code from ROM starting at location
__iwram_lma and ending at __iwram_end to address 0x3000000. from this
point your iwram routines are ready to be called.

i hope i could clarify it a bit..

there is also a solution how to manage your iwram code dynamically, in
case you are running out of internal ram. to do that, you can use
.iwram0 - .iwram9 sections which are overlayed by the linkscript, i.e.
the same internal ram virtual memory address is assigned to all these
sections. you just have to copy the code at runtime manually before
calling methods or accessing data from overlayed sections. for details
just look at jeffs linkscript and crt0.s

Dima

nevermind...Just a stupid error on my part.
-dovoto

----- Original Message -----
From: "Dima" <dmitri.dev@...>
To: <gbadev@yahoogroups.com>
Sent: Monday, December 03, 2001 9:16 AM
Subject: RE: [gbadev] A bit of the old IN-OUT!!


> just the same way :)
>
> class foo
> {
> public:
> void fun(u32 a, u32 b)
> __attribute__((section(".iwram"),long_call));
> };
>

[cropped by mod  (grr.. :) ]

Parse error before token ;    Did you try this?  Mabey there is something I
am missing.
-dovoto
----- Original Message -----
From: "Dima" <dmitri.dev@...>
To: <gbadev@yahoogroups.com>
Sent: Monday, December 03, 2001 9:16 AM
Subject: RE: [gbadev] A bit of the old IN-OUT!!


> just the same way :)
>
> class foo
> {
> public:
> void fun(u32 a, u32 b)
> __attribute__((section(".iwram"),long_call));
> };
>

[cropped by mod]

just the same way :)

class foo
{
public:
	 void fun(u32 a, u32 b)
__attribute__((section(".iwram"),long_call));
};

void foo::fun(u32 a, u32 b)
{
	 // impl
}

jason rogers wrote:
> Even Better:)   NOw how do I do that with a c++ function?
> -dovoto

Dima wrote:
> > ARM can't branch to far locations using short calls, which compiler
> > generates by default. so if you place a method in iwram or
> ewram and
> > want
> to
> > call it from gamepack rom, you should also add long_call attribute,
> > like
> > this:
> >
> > void fun(void) __attribute__((section(".iwram"),long_call));
> >
> > void fun(void)
> > {
> >     //do stuff
> > }

Even Better:)   NOw how do I do that with a c++ function?
-dovoto
----- Original Message -----
From: "Dima" <dmitri.dev@...>
To: <gbadev@yahoogroups.com>
Sent: Wednesday, November 28, 2001 5:43 AM
Subject: Re: [gbadev] A bit of the old IN-OUT!!


> ARM can't branch to far locations using short calls, which compiler
> generates by default. so if you place a method in iwram or ewram and want
to
> call it from gamepack rom, you should also add long_call attribute, like
> this:
>
> void fun(void) __attribute__((section(".iwram"),long_call));
>
> void fun(void)
> {
>     //do stuff
> }
>
> > with devkit advanced it is very simple.  just define these:
> >
> > #define IN_EWRAM __attribute__ ((section (".ewram")))
> > #define IN_IWRAM __attribute__ ((section (".iwram")))
>
> [cropped by mod]
>
>
>
> list rules: http://www.gbadev.org/rules.txt
> unsubscribe: gbadev-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

On Fri, 30 Nov 2001, Dave Mariner wrote:

> Hi,
>     I put FreeBSD on my lappy the other day - although I haven't got any of
> my devtools over yet (first attempt with BSD), so that brings the total up
> to 3.....if there's enough interest I'll set up a dedicated FreeBSD/GBADev
> website ... what d'ya reckon?

Very interesting, so it push the height of people awareness of
NonWindows/GBADevving. I also wish to see a *BSD port of Boycott Advance
(and a native *nix debugger interface for this nice emulator :) )

Ciao.
--
                      Davide "Gatto Feroce" Inglima
   " Paradosso Invernale: perche' d'inverno se apri la <<window>> entrano "
         " i <<pinguini>>? " citando Luigi Catuogno a.k.a Kenshy
                    http://digilander.iol.it/nekochan/

and now,
<os> emulates java,
java emulates gba,
gba emulates speccy :]


  - Graham Reeves
______________________________________
(new project)
  http://www.ferk.co.uk/
(old demos and archived things)
  http://www.deadpenguin.org/
(i make games for a living)
  http://www.eurocom.co.uk/
(contact)
  mailto:graham@...





----- Original Message -----
From: "Daniel Papenburg" <papenbd@...>
To: <gbadev@yahoogroups.com>
Sent: Saturday, December 01, 2001 2:47 PM
Subject: [gbadev] OT: Java->gba emulator


> A GBA emulator in Java. Hehe. Kinda funny, if you ask me. One machine
> emulates another, which is in turn emulating another machine with
> advanced hardware capabilities.  =P  I have a deep respect for emulator
> authors (good ones) - it takes a lot of work - but even more for someone
> who can program a Java gba emulator that runs accurately and at full
> speed. Just seems kinda round-about to me, but at least it's portable.
> (I haven't used it.)  I'm not starting a battle here, so I don't really
> expect/want any replies, thx.
>
> DP
>
>
>
>
> list rules: http://www.gbadev.org/rules.txt
> unsubscribe: gbadev-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Howdy amigos,

I wrote a library a while back that creates bitmap fonts for the
following languages (from TTF fonts):

Arabic
Hebrew
Latin (Western European)
East European
Cyrillic
Baltic
East European
Greek
Turkish
Thai
Korean
Japanese (SHIFT-JIS)
Simplified Chinese
Traditional Chinese.

The library does complex text processing (Arabic) and has extra API
for handling double byte languages (CJK). I wrote the software for a
client who wanted their DOS based industrial machine to display these
languages on LCD.

I am seriously thinking of rewriting the library to optimise it for
GameBoy Advance... Would anyone be interested in such a thing? would
it have any commercial value?

Please give me a shout if you are interested...  Some of the API
would need rewriting in Assembly (to make it faster) and I may need
some help..

Mo.

Arrgh!!!

Could anybody tell me what is the fraggin' problem with the sound
channel 3??? I've wasted a full day trying to make it work and all i
get is silence! What is very annoying is that all my emulators plays
the sound but not the real hardware!!! Here my code:

	 REG_SOUNDCNT_L=0xFF77; //all sounds to l&r output
	 REG_SOUNDCNT_H=0x02; //sound ratio=100%
	 REG_SOUNDCNT_X=0x008F; //turn on sound chip

	 REG_SOUND3CNT_L=0;

	 REG_WAVE_RAM0=0x01234567;
	 REG_WAVE_RAM1=0x89abcdef;
	 REG_WAVE_RAM2=0x01234567;
	 REG_WAVE_RAM3=0x89abcdef;

	 REG_SOUND3CNT_L=0x80; //sound 3 enable
	 REG_SOUND3CNT_H=0x2000; //sound 3 vol=max
	 REG_SOUND3CNT_X=0x8100; //sound 3 reset+freq

I'd like to mention that using -O2 optimizations with Gcc gave me
trouble with other sound channel because of instruction re-odering.
But I removed all optimization and I still have problems with chan 3.
Any help would be *greatly* appreciated, thanks!

Uze

Hi guys,

Yet another release of FontMapper, hopefully the last for awhile. This
release addresses a major issue about the font widths (they were all 0) and
adds detailed width info (leading, glyph, trailing) for TrueType fonts.

FontMapper v0.13 is available at:
www.epicentrix.net/~ltan/software.html

Cheers,
Soulshift aka. Hitomi_Ch

========================================
FontMapper is a small tool that allows you to save Windows
fonts in a bitmap format suitable for use in games and other
applications.

FontMapper is free for commercial or non-commercial use :)

Features:
+ User configurable font, grid size, character width/height/color
+ Saves an array of font widths as C/C++ source code
+ Also saves detailed character spacing info for TrueType fonts
+ Optionally renders text with either Sub-Pixel Font Rendering
     technology or standard whole pixel anti-aliasing

Known limitations/issues:
- Font display will extend off the viewable area if a large grid
    size is selected
- Sub-Pixel rendering not compatable with certain color
    combinations; use anti-aliasing instead

Please note that FontMapper is more or less in an experimental
stage, so please send comments/feedback/suggestions to:
ltan@....

ChangeLog:
v0.13
= Fixed major bug with font widths not being
    recorded (Chris Sorrell)
= Added detailed character spacing info to output
= Fixed minor file saving bugs

v0.11
= Added sub-pixel font rendering (Codac)
= Added anti-aliased font rendering
= Added user tweakable font widths and heights
= Some UI enhancements

v0.01
= Initial Release
=====================================

> You are of course throwing resolution away if you use the 7-bit or 6-bit
> modes.  The low bit(s) are just gone.  In 9-bit mode the extra bit is just
> "invented" by the system so it's still just 8-bit sound.

Well, I thought I explained this.  The reason that argument is not calid can
be attacked from two different angles:

1) If you move from 8-bit to 9-bit, though you gain resolution in sample
depth, you lose resolution in sample rate.  That extra timing bits are, to
quote, "just gone".

2) The sound card pushes the same amount of data per second no matter what
mode you're in, implying that no loss of resolution has occurred, but rather
a shift in resolution.

Here's a hint: don't say "of course".  That's a really dangerous phrase,
especially when your substantiation of why rigorously ignored half of what's
going on.

> In 9-bit mode the extra bit is just
> "invented" by the system so it's still just 8-bit sound.

Can anyone confirm this?  This seems ludicrous to me, and I've never seen
anythign which supports this.  Moreover, when I generated tones through the
AGB, I was able to tell the difference, when using waveforms whose timing
was adjusted to be different.

That said, there's been some indication on the list that a waveform expanded
to fill different timing rates somehow sounds different, so I worry that
that's what I'm hearing.

The nine bits of data *are* being interpreted by the system.  Otherwise,
that ninth bit I put in the waveform should have wreaked havoc, and it
didn't.  Moreover, 8-bit data filled in in the 9-bit mode sounds completely
wrong, leading me to suspect that you're just making that up.

> The balance between sample rate and sample depth is most elegantly exposed
> using PWM.  Roughly speaking, you can double your sample rate and half
your
> dynamic range [= drop 1 bit from the sample depth] and the sound quality
is
> equivalent [i.e. identical, assuming proper analog output stages].

Instead of picking on the grammar here (start with a question, end with a
statement attatched with an "and"), I'm gonig to point out that

a) sound quality is *certainly* *not* equivalent, and if you were to try the
MP3 experiment I described, you'd know that, and
b) if it were equivalent, how could you possibly be losing resolution?

> PWM is
> essentially 1 bit at very high speed, and it *emulates* 8 bits and 65kHz,
or
> 9 bits at 32kHz, etc.  There is no reason to choose one over the other in
> principle because the DATA RATE is the same, and it's data rate that
counts.
> However, the analog shaping circuitry at the output stage makes a BIG
> difference here.  Not knowing what the output stage is exactly, the only
> valid advice is to try the different modes and choose the one that sounds
> best.

Uh, no.  While it is true that PWM is a 1-bit signal constructed into
varying rates, there are absolute scads of logical errors.  If the sound
quality is equivalent, what's this about testing to see which sounds best?
And what makes you think that it cannot be predicted what effects sample
rate and sample depth will have on a sample?

> I don't understand where FM comes in.  GBA uses Pulse Width Modulation,
not
> Frequency Modulation.  FM uses sine waves; PWM does not.

Brain fart.  I tend to use FM to mean sampled sound, because most people
recognize it that way, much like I tend to use Hacker to mean Cracker, even
though the word is just wrong.  That said, this is a technical forum and I
shouldn't have.  My bad.

> Another hint from DSP theory: if you calculate the sounds internally at
> higher than 8-bit resolution, then you should add a certain amount of
noise
> [dithering] before you cast the sample to 8 bits.  The dithering should be
a
> random amount between -0.5 and +0.5.  The difference is marginal at 16
bits,
> but at 8 bits it is audibly noticeable.  In experiments, it has been found
> that people can hear a sine wave that is only 1/2 LSB large AS A SINE WAVE
> when 1/2 LSB of noise is added.  Without the noise added, all you hear is
a
> SQUARE wave.  That's a big difference at low amplitudes.  Think of how a
> greyscale image would look with and without dithering - your ear works the
> same.

Um.  I'm not a sound technician.  +0.5 what, and -0.5 what?  Why would
adding noise make something sound better?  Is this to combat aliasing?  If
so, why not just approach the aliasing from a known position?  Certainly
there's something better than randomness.  For that matter, if random noise
is good, why are uninsulated cables bad?  They're not getting very much
amplitude compared to the real signal at all, and though +0.5 has *no*
*unit* (this is bad, 3rd grade math), I'm assuming you mean against a signal
level of one.  I don't know whether line amplitude is measured linearly or
logarithmically, but either way, I'd be hella surprised to learn it went
over 0.5 on a scale of 1 unknown unit.

That said, unless you're a sound engineer, that paragraph is completely
incomprehensible.  And I'm kind of hesitant to believe that a sine wave,
when played wihtout noise, sounds liek a square wave when listened to.  Or
whatever you meant.

Look, you seem to know a lot about the topic, but what you say is
self-contradictory.  Let's put the debate to rest: the amount of data flow
is unchanging, and there is no compression involved, so there is no
resolution loss.  This is very simply put.  The sample rate can have a
difference in resolution, *or* the sample depth can have a loss in
resolution, but the sample itself cannot, as the rate and the depth will
mirror each other.

If you're discarding sample rate, then yes, sample depth can lose
resolution, but that seems to me to be a clearly erroneous thing to do.  The
bitrate is unchanging, and I'd like to see you address that.

In the meantime, what's all this about random noise making things sound
better?  If you mean that the dither pattern has a random component, that's
different, but those aren't random - tehy're pseudo-random, and in the case
of dithering patterns, not very - they have rules regarding neighbors, etc.
That's very different than random noise and should not be presented as such.

Dithering seems like entirely the wrong word to use, by the way.  Dithering
is a term used specifically to refer to graphics, especially bitmap
graphics.  It comes from the old english word, meaning to shiver (merriam
webster online comes up with that one; the better definition can be found at
FOLDOC.org).

Now, I'm not claiming to know how people on the inside of the digital audio
industry talk about things, but I think it's curious that every single one
of the pages I come up with uses the phrase "anti-aliasing".

So, look.  Your last message neatly restated what you said before, but did
not address any of the concerns I raised as to why I think you're wrong, so
I still think you're wrong.  If you have a good way of demonstrating to me
that the *total* resolution - sample rate and sample depth - is changed by
this operation, I'll take it.  Do remember, as I keep restating, that the
data rate is unchanged.

For the sake of this list, I'm gonna drop the thread, unless his new reply
actually addresses some of these topics.

- Fatty the somewhat annoyed
("of course" indeed)


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

> "John Q. Pretentious" <johnisaheadcase@...> wrote:
>
> > I think it's so that N's games can be stronger in the pimp-force than
> > mere outsider titles.
>
> Only if gamers are into shiny things (which the early non-gamma-
> corrected titles can't easily provide).

Or big games.  Yes, large cart space is likely to be used more for eye-candy
than anything else.  But anyone who's played angband or nethack knows that
game rules systems can easily stretch into multiple megabyes, and if you
were to *just* put tiles in that game, but had 8-direction views like DooM
did, I'd be willing to wager that you could break 8 megabytes without
difficulty.

In the meantime, you seem to be forgetting that for console games, Eye Candy
can be *the* difference in sales.  Therefore, this is a big deal, whether
it's aimed at eye candy or not.  Kids are notoriously easily impressed by
flashy things.

> I've seen some good stuff crammed
> into 8 megabits (i.e. 1 megabyte) especially on Sega Genesis, with
> titles such as Sonic 2, Zero Wing, and Gunstar Heroes.

Yep.  And I wrote a 7k tetris app for DOS.  That doesn't mean that the extra
space can't be used for less than shallow things.

Yes, I know it always seems to be.  But we can fix that.

> It all depends
> on how resourcefully the artists can use a limited tile set, how well the
> programmers can optimize their compression, and how well the system
> can synthesize music in real time (Genesis had an FM chip and used
> ROM-hogging PCM only for some complex instruments and the
> "Sega" choir in the intro screen).

And how big your game is.  Don't forget Angband.  2.3 megabytes of no
graphics, almost no sound, and certainly no cutscenes.

> > That said, no, it's not an issue of cost: The big N is not allowing
anyone
> > to produce games larger than 8m, and won't even let themselves release
and
> > >16m games.  Those limits are due to shift in a few months, I'm told, to
N
> > w/ 32m and outside developers getting 16m carts.
>
> Now by "8m" are we talking megabits, megabytes, or megawords?
> THQ's Tetris(R) Worlds is 32 megabits or 4 megabytes.

Sorry.  8 megabyes is the outsider limit - 1/4 of the max addressable size.
N's limiting themselves to 16megabytes right now.  Like I said, both limits
are due to be doubled soon (sorry, I don't know better than "a couple of
months"), giving outsiders 1/2 space, and N use of the full space.

> > > how else are Nintendo supposed to keep
> > > their games one step ahead of everyone else's? :0)
> >
> > By hiring better programmers and game designers.  When Microsoft
> > did this by obscuring certain useful parts of the Windows 98 API, people
> > were up in arms.  They have enough clout to spank us through fair play.
> > I think they ought to.
>
> Before you make a hasty comparison to Microsoft's practices,
> remember that Microsoft makes game consoles now.

Why?  The comparison stands.  It wasn't hasty at all.  In fact, if Microsoft
were to do this with the X-Box, SlashDot would be on fire, right now.

> > Heh.  That's what I get for thinking this is an all-amateur list.
>
> Some of us are just used to nesdev and the like, which are all-amateur.

<nods>

> Or better yet to learn to write your reply directly under what you're
> replying to and cut out what you're not.  See also
> http://www.google.com/search?q=usenet+top-posting

That's not always an option.  For instance, I post from work, where I'm
required to use Outlook.  It's a pain in the ass with Outlook if you're
using HTML mail, because the quoted message line *just* *won't* *break*.

Besides, that's stylistic.  While I and most conscious individuals agree
with you, it's not a definate point.  The extra copies of ads I get from
Yahoo! footers, on the other hand, seem pretty hard to defend.

- Fatzilla


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

A GBA emulator in Java. Hehe. Kinda funny, if you ask me. One machine
emulates another, which is in turn emulating another machine with
advanced hardware capabilities.  =P  I have a deep respect for emulator
authors (good ones) - it takes a lot of work - but even more for someone
who can program a Java gba emulator that runs accurately and at full
speed. Just seems kinda round-about to me, but at least it's portable.
(I haven't used it.)  I'm not starting a battle here, so I don't really
expect/want any replies, thx.

DP

You are of course throwing resolution away if you use the 7-bit or 6-bit
modes.  The low bit(s) are just gone.  In 9-bit mode the extra bit is just
"invented" by the system so it's still just 8-bit sound.

The balance between sample rate and sample depth is most elegantly exposed
using PWM.  Roughly speaking, you can double your sample rate and half your
dynamic range [= drop 1 bit from the sample depth] and the sound quality is
equivalent [i.e. identical, assuming proper analog output stages].  PWM is
essentially 1 bit at very high speed, and it *emulates* 8 bits and 65kHz, or
9 bits at 32kHz, etc.  There is no reason to choose one over the other in
principle because the DATA RATE is the same, and it's data rate that counts.
However, the analog shaping circuitry at the output stage makes a BIG
difference here.  Not knowing what the output stage is exactly, the only
valid advice is to try the different modes and choose the one that sounds
best.

I don't understand where FM comes in.  GBA uses Pulse Width Modulation, not
Frequency Modulation.  FM uses sine waves; PWM does not.

Another hint from DSP theory: if you calculate the sounds internally at
higher than 8-bit resolution, then you should add a certain amount of noise
[dithering] before you cast the sample to 8 bits.  The dithering should be a
random amount between -0.5 and +0.5.  The difference is marginal at 16 bits,
but at 8 bits it is audibly noticeable.  In experiments, it has been found
that people can hear a sine wave that is only 1/2 LSB large AS A SINE WAVE
when 1/2 LSB of noise is added.  Without the noise added, all you hear is a
SQUARE wave.  That's a big difference at low amplitudes.  Think of how a
greyscale image would look with and without dithering - your ear works the
same.

HTH,

Ed xxx

-----Original Message-----
From: John Q. Pretentious [mailto:johnisaheadcase@...]
Sent: Saturday, December 01, 2001 12:19 AM
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] Re: Sound Bias Register - 9bit samples????


> I read:
> > You're not throwing resolution away.
>
> if I understand it right of courswe you are

You're exchanging sample depth for sample rate.  Whenever your samples are
half the resolution, their timing is twice the resolution.

You are *not* throwing resolution away.  You've always got a 32khz sample at
64khz, and three multipliers (always *2) to spread around as you see fit.

> > You're just applying the time differently.  I think it's rather elegant,
> > but unfortunately, I don't know enough about sound to know why you'd
> > want one over the other
>
> bitdepth = resolution = headroom (kind of)

Uh, no.  Sample depth is the accuracy to which a tone is recorded.  This is
the step distance between tones.

> the idea is that the more bits you use to store a single sample
> (which is basically just the volume or the voltage on the wire)
> the finer grained your resolution in the digital representaion
> will be.
> the so called time domain representation holds no frequency information
> about a sound, just levels(=amplitudes)
> sample rate OTOH defines the speed at which the conversion of said samples
> D->A or vice versa takes place.

At the most technical level, this is correct, but it belies a fundamental
misunderstanding of the characteristics of FM sound.

Rate most certainly *is* a factor in audio sample resolution.  It's one of
four, of which the gameboy supports three: sample depth, sample rate,
channel count, and channel placement (the AGB supports the first three).

People argue which of sample depth or sample rate is more significant.  In
my opinion, they're roughly equivalent - if *either* goes too low, things
begin to suck.

The practical effects of sample depth are the accuracy in tonality that we
percieve as "off-key" when it gets bad.  In order to get a handle on this,
grab your favorite Primus CD (or a female jazz vocalist who moves through a
note slowly somewhere, or a saxophone).  Rip it in MP3 at CD rate - 44.1/16.
Record it again at 44.1/8.  You'll notice that your singer seems to miss her
note every so often.

In order to understand sample rate, consider how "grainy" a song sounds on
old but good condition audio tapes.  Things with extremely fast timing -
especially drum beats in German techno from the 80s - will really show up
low bitrate samples.  You'll get the impression that the tape just couldn't
keep up.

> As you might know the highest possible frequency that can be accurately
> represented in a discrete way is srate/2 (the Nyquist freq.)

It's curious that you know what the nyquist frequency is, that you know that
it involves sample rate, that it limits sample resolution, and that you
still don't think that sample rate is involved in audio resolution.

For those of you who don't know what the Nyquist frequency is, it's the
sample rate cut in half - the rate at which our ears will hear aliasing.
Low-bandwidth pass at the nyquist frequency and your audio will be clean,
clean, clean.

A good explanation of how the Nyquist frequency works is buried in this page
that explains Fast Fourier Transforms:
    http://www.daqarta.com/0t0cfft2.htm

> so if you need high frequencies but don't care about the headroom (the
> number of distict levels) go for higher srates, if you can get by with
> frequencies below you can opt for the higher resolution.

Well, this is the part that I meant when I said I didn't know enough about
sound.  It's not that I don't understand how an FM sample works - that's
pretrty easy.  I just don't know when rate is desirable, and when sample
depth is desirable.  I'm supposing that depth is the default, and that rate
is desirable when depth is a non-issue - say, in sampled speech, where the
tonal range is miniscule, or what have you.

- Fattrini, Alto Tenor Contralto Basso of the 5th nebula of Zorticulon X

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


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



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

"John Q. Pretentious" <johnisaheadcase@...> wrote:

> I think it's so that N's games can be stronger in the pimp-force than
> mere outsider titles.

Only if gamers are into shiny things (which the early non-gamma-
corrected titles can't easily provide).  I've seen some good stuff crammed
into 8 megabits (i.e. 1 megabyte) especially on Sega Genesis, with
titles such as Sonic 2, Zero Wing, and Gunstar Heroes.  It all depends
on how resourcefully the artists can use a limited tile set, how well the
programmers can optimize their compression, and how well the system
can synthesize music in real time (Genesis had an FM chip and used
ROM-hogging PCM only for some complex instruments and the
"Sega" choir in the intro screen).

> That said, no, it's not an issue of cost: The big N is not allowing anyone
> to produce games larger than 8m, and won't even let themselves release and
> >16m games.  Those limits are due to shift in a few months, I'm told, to N
> w/ 32m and outside developers getting 16m carts.

Now by "8m" are we talking megabits, megabytes, or megawords?
THQ's Tetris(R) Worlds is 32 megabits or 4 megabytes.

> > how else are Nintendo supposed to keep
> > their games one step ahead of everyone else's? :0)
>
> By hiring better programmers and game designers.  When Microsoft
> did this by obscuring certain useful parts of the Windows 98 API, people
> were up in arms.  They have enough clout to spank us through fair play.
> I think they ought to.

Before you make a hasty comparison to Microsoft's practices,
remember that Microsoft makes game consoles now.

> Heh.  That's what I get for thinking this is an all-amateur list.

Some of us are just used to nesdev and the like, which are all-amateur.


> (People need to learn to trim the footers out of replies.)

Or better yet to learn to write your reply directly under what you're
replying to and cut out what you're not.  See also
http://www.google.com/search?q=usenet+top-posting

Toby Hutton writes:
  > Hello,
  >
  > I'm new here, thought I'd delurk.  I'm curious - does anyone use
  > FreeBSD for GBA dev?  I am just starting out, and the first thing I
  > did was port ('translate' is probably a better word) Jeff F's flash...

Hrrm, I posted that message from a website... sorry for the lack of
wrapping.

Cool, ok there seems to be some interest in both a FreeBSD flash
client and the gimp plugin.  Both are in a primitive state - I'll fix
them up over the weekend and whack them on my website.

I'd better contact Jeff and make sure it's ok to port his code.  Jeff?
--
Toby.

> [removed by mod: Dont think it is suitable to write
> how you came to that conclusion on a gba dev list with many licenced gba
> developers, therefor I chose to remove it]

Eep.  Good call.

Heh.  That's what I get for thinking this is an all-amateur list.

FWIW, it's probably not what anybody's gonna guess.  I just said something I
shouldn't have.  Bad fatty.

- Fatty


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