Hi,
I am working on a GB cartridge for GBA with 16Mb Flash and 1-4Mb
SRAM, the pricing of the unit depends highly on your volume,
packaging etc.

For prototype I would say something arround 30-50, but in volume
production (say in 1000s) it will be 10-20 depending on the
complexity of you device number of IO you have how much else you
need on that board etc.

BR,
/Farhad
--- In gbadev@yahoogroups.com, Hari Nair <harinnair@y...> wrote:
>
> Hi,
>
> I'm new to this forum - i've been interested in developing hw/sw
> applications for the GBA more as a novelty, but am now wondering
> whether it is commercially viable to actually ROM an application.
>
> My development/prototyping platform is VHAM and an F2A 64Mb card.
The
> kind of applications I am developing would normally fit in less
than
> 16Mb  - data logging/instrumentation type of stuff, but I would
need
> battery backed SRAM as well.
>
> What kind of volume commitments/pricing would one expect for
ROMing an
> application like this ? Any pointers would be much appreciated.
>
> HN
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Find what you need with new enhanced search.
> http://info.mail.yahoo.com/mail_250

Hi,

I'm new to this forum - i've been interested in developing hw/sw
applications for the GBA more as a novelty, but am now wondering
whether it is commercially viable to actually ROM an application.

My development/prototyping platform is VHAM and an F2A 64Mb card. The
kind of applications I am developing would normally fit in less than
16Mb  - data logging/instrumentation type of stuff, but I would need
battery backed SRAM as well.

What kind of volume commitments/pricing would one expect for ROMing an
application like this ? Any pointers would be much appreciated.

HN



__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

----- Original Message -----
From: "Joe McKenzie" <me@...>
To: <gbadev@yahoogroups.com>
Sent: Monday, December 06, 2004 5:02 PM
Subject: Re: [gbadev] Re: Creating an e-reader program


>
>
> dracosilver_furcadia wrote:
>
>>
>>--- In gbadev@yahoogroups.com, Joe McKenzie <me@j...> wrote:
>>
>>
>>>dracosilver_furcadia wrote:
>>>
>>>
>>>
>>>>How would i go about creating a program for the e-reader and
>>>>compiling/testing it?  I can figure out how to create the dot-codes
>>>>from the files, but creating those files is what I can't figure out.
>>>>
>>>>Any help is appreciated.
>>>>
>>>>Thanks!
>>>>
>>>>Sincerely,
>>>>Jonathan Herr
>>>>
>>>>
>>>Somebody cracked the encryption/CRC on the dotcodes and wrote a program
>>>to convert the raw program and data into a bitmap.  There's another
>>>program to print the bitmaps.  (Remember to cut the margin the right
>>>size; use an official card as a sample.)  You can't just print them from
>>>any program because the scaling messes up the dots' readability.  I
>>>tried to print the Bombsweeper sample program on my Lexmark Z22, but I
>>>just kept getting read errors on both normal inkjet paper and Kodak
>>>photo paper.  Later I might try using an older (really stubborn) inkjet
>>>or a really old 24-pin dot-matrix.  The author's suggestion to correct
>>>this is to examine the printed output with a scanner or microscope and
>>>see if you can see any problems.  Also try other DPI settings.  (The
>>>output is never quite the same size as an official dotcode, but this
>>>doesn't seem to bother the eReader, but trying to scale it to the right
>>>size makes it completely unreadable.)
>>>The actual tools:
>>>http://users.skynet.be/firefly/gba/e-reader/tools/index.htm
>>>Some info: http://users.skynet.be/firefly/gba/e-reader/index.htm
>>>
>>>-Joe McKenzie
>>>
>>>
>>
>>So with those tools I should be able to create the raw programs and data?
>>
>
> The "Nintendo e-Reader Z80 Assembler and Linker v1.0" package
> (http://users.skynet.be/firefly/gba/e-reader/tools/asxxxx_z80_ereader_10.zip)
> can be used to write programs for the e-Reader's Z80 emulation mode.
> (See the e-Reader Z80 API info at
> http://users.skynet.be/firefly/gba/e-reader/api_z80.htm if you want to
> use graphics, sound or input.)  The e-Reader also has a built-in NES
> emulator, which can run NES mapper type 0 games.  Use a NES
> compiler/assembler to write these.  The e-Reader can also run normal GBA
> code, which you would make using a GBA compiler.  (Though I don't know
> where the entry point is....)
> Nintendo only uses NES mode (for ports of old NES games) and Z80 mode
> (for stuff like the Pokemon card mini-games).  They only use GBA mode
> for loaders to transmit data to games (like the Animal Corssing cards).
> This is probably because GBA code takes up so much space, it would take
> too many cards to store any decent game.
> Once you write your program, you'll need the RAW to BMP program
> (http://users.skynet.be/firefly/gba/download/raw-to-bmp-v11.zip) to
> convert the raw data into bitmaps and the dotcode print tool
> (http://users.skynet.be/firefly/gba/e-reader/tools/dotcode-print-v10.zip)
> to print them.  (1200 dpi on photo paper is recommended for best
> results, though I've yet to print a dotcode that doesn't create a read
> error.)
> Also look at the other programs (and samples) there.  The flash maker
> looks particularly useful; it converts e-Reader programs into regular
> GBA ROMs, which would let you test and debug them with an emulator
> instead of printing out each revision only to watch it crash.
>
> -Joe McKenzie

I believe the Z80 entrypoint is 0x100.

For the gba code type, it is 0x2000000.   At this location,  the CRT0
needed, is nothing like the CRT0 used for compiling a multiboot game.
Basically, the code is something like this.

.TEXT
.ARM
_start:
LDR R0, =(_start_thumb+1)
BX R0

.THUMB
_start_thumb:

Push {LR} @ save the return address.
@ BSS clearing loop here
POP {R3}
MOV LR, R3
LDR R3, =main
BX R3

.ALIGN
.POOL
.END.


Basically,  you have no header, no nintendo logo data,  no header checksums.

This also means, when main returns,  your back in the e-reader menu again.

dracosilver_furcadia wrote:

>
>--- In gbadev@yahoogroups.com, Joe McKenzie <me@j...> wrote:
>
>
>>dracosilver_furcadia wrote:
>>
>>
>>
>>>How would i go about creating a program for the e-reader and
>>>compiling/testing it?  I can figure out how to create the dot-codes
>>>from the files, but creating those files is what I can't figure out.
>>>
>>>Any help is appreciated.
>>>
>>>Thanks!
>>>
>>>Sincerely,
>>>Jonathan Herr
>>>
>>>
>>Somebody cracked the encryption/CRC on the dotcodes and wrote a program
>>to convert the raw program and data into a bitmap.  There's another
>>program to print the bitmaps.  (Remember to cut the margin the right
>>size; use an official card as a sample.)  You can't just print them from
>>any program because the scaling messes up the dots' readability.  I
>>tried to print the Bombsweeper sample program on my Lexmark Z22, but I
>>just kept getting read errors on both normal inkjet paper and Kodak
>>photo paper.  Later I might try using an older (really stubborn) inkjet
>>or a really old 24-pin dot-matrix.  The author's suggestion to correct
>>this is to examine the printed output with a scanner or microscope and
>>see if you can see any problems.  Also try other DPI settings.  (The
>>output is never quite the same size as an official dotcode, but this
>>doesn't seem to bother the eReader, but trying to scale it to the right
>>size makes it completely unreadable.)
>>The actual tools:
>>http://users.skynet.be/firefly/gba/e-reader/tools/index.htm
>>Some info: http://users.skynet.be/firefly/gba/e-reader/index.htm
>>
>>-Joe McKenzie
>>
>>
>
>So with those tools I should be able to create the raw programs and data?
>

The "Nintendo e-Reader Z80 Assembler and Linker v1.0" package
(http://users.skynet.be/firefly/gba/e-reader/tools/asxxxx_z80_ereader_10.zip)
can be used to write programs for the e-Reader's Z80 emulation mode.
(See the e-Reader Z80 API info at
http://users.skynet.be/firefly/gba/e-reader/api_z80.htm if you want to
use graphics, sound or input.)  The e-Reader also has a built-in NES
emulator, which can run NES mapper type 0 games.  Use a NES
compiler/assembler to write these.  The e-Reader can also run normal GBA
code, which you would make using a GBA compiler.  (Though I don't know
where the entry point is....)
Nintendo only uses NES mode (for ports of old NES games) and Z80 mode
(for stuff like the Pokemon card mini-games).  They only use GBA mode
for loaders to transmit data to games (like the Animal Corssing cards).
This is probably because GBA code takes up so much space, it would take
too many cards to store any decent game.
Once you write your program, you'll need the RAW to BMP program
(http://users.skynet.be/firefly/gba/download/raw-to-bmp-v11.zip) to
convert the raw data into bitmaps and the dotcode print tool
(http://users.skynet.be/firefly/gba/e-reader/tools/dotcode-print-v10.zip)
to print them.  (1200 dpi on photo paper is recommended for best
results, though I've yet to print a dotcode that doesn't create a read
error.)
Also look at the other programs (and samples) there.  The flash maker
looks particularly useful; it converts e-Reader programs into regular
GBA ROMs, which would let you test and debug them with an emulator
instead of printing out each revision only to watch it crash.

-Joe McKenzie

Remember N-Scene? Well we're back and our forums are live and
accepting subscribers...

Please visit:
http://www.gci.net.tc/

Our website is being worked on and will launch shortly.


Laters, Dave (N-Scene Administrator)

--- In gbadev@yahoogroups.com, Joe McKenzie <me@j...> wrote:
>
> dracosilver_furcadia wrote:
>
> >
> >
> > How would i go about creating a program for the e-reader and
> > compiling/testing it?  I can figure out how to create the dot-codes
> > from the files, but creating those files is what I can't figure out.
> >
> > Any help is appreciated.
> >
> > Thanks!
> >
> > Sincerely,
> > Jonathan Herr
>
> Somebody cracked the encryption/CRC on the dotcodes and wrote a program
> to convert the raw program and data into a bitmap.  There's another
> program to print the bitmaps.  (Remember to cut the margin the right
> size; use an official card as a sample.)  You can't just print them from
> any program because the scaling messes up the dots' readability.  I
> tried to print the Bombsweeper sample program on my Lexmark Z22, but I
> just kept getting read errors on both normal inkjet paper and Kodak
> photo paper.  Later I might try using an older (really stubborn) inkjet
> or a really old 24-pin dot-matrix.  The author's suggestion to correct
> this is to examine the printed output with a scanner or microscope and
> see if you can see any problems.  Also try other DPI settings.  (The
> output is never quite the same size as an official dotcode, but this
> doesn't seem to bother the eReader, but trying to scale it to the right
> size makes it completely unreadable.)
> The actual tools:
> http://users.skynet.be/firefly/gba/e-reader/tools/index.htm
> Some info: http://users.skynet.be/firefly/gba/e-reader/index.htm
>
> -Joe McKenzie

So with those tools I should be able to create the raw programs and data?

dracosilver_furcadia wrote:

>
>
> How would i go about creating a program for the e-reader and
> compiling/testing it?  I can figure out how to create the dot-codes
> from the files, but creating those files is what I can't figure out.
>
> Any help is appreciated.
>
> Thanks!
>
> Sincerely,
> Jonathan Herr

Somebody cracked the encryption/CRC on the dotcodes and wrote a program
to convert the raw program and data into a bitmap.  There's another
program to print the bitmaps.  (Remember to cut the margin the right
size; use an official card as a sample.)  You can't just print them from
any program because the scaling messes up the dots' readability.  I
tried to print the Bombsweeper sample program on my Lexmark Z22, but I
just kept getting read errors on both normal inkjet paper and Kodak
photo paper.  Later I might try using an older (really stubborn) inkjet
or a really old 24-pin dot-matrix.  The author's suggestion to correct
this is to examine the printed output with a scanner or microscope and
see if you can see any problems.  Also try other DPI settings.  (The
output is never quite the same size as an official dotcode, but this
doesn't seem to bother the eReader, but trying to scale it to the right
size makes it completely unreadable.)
The actual tools:
http://users.skynet.be/firefly/gba/e-reader/tools/index.htm
Some info: http://users.skynet.be/firefly/gba/e-reader/index.htm

-Joe McKenzie

I read in the Devrs FAQ that the little pot in the original GBA controls
the voltage to the LCD.  Is this the same as the one in the SP's battery
compartment?  If so, could somebody please tell me the correct
resistance of this thing (or a way to measure the net voltage over time
to the LCD -- Note that I don't have a graphing multimeter, just a
normal one)?  I messed with it before I read that it could shorten the
life of the LCD.

Thanks.
-Joe McKenzie

How would i go about creating a program for the e-reader and
compiling/testing it?  I can figure out how to create the dot-codes
from the files, but creating those files is what I can't figure out.

Any help is appreciated.

Thanks!

Sincerely,
Jonathan Herr

Hi all,

Just want to inform you that our company Two Tribes, a Dutch gamedeveloper,
is looking for talented people to join our development team, both
programmers and designers are welcome. Two Tribes focusses mainly on
portable videogames, ranging from the most humble mobile phone to for
instance the GBA, the new Nintendo DS or Sony's PSP.

Interested, please take a look at: http://www.twotribes.com/jobs/

Regards,

Martijn Reuvers

<kevinweatherman@h...> wrote:
>
> So you could use a number of IDE/UI's for your developement besides
MSDEV.
> What ever your developement platform is Windows or Linux, etc.
> But you have to set it up to point to your Assembler, linker, and
compliers.

    I figured this was the case, and that I just didn't know what I
was doing. I have MS Visual Studio v6 installed somewhere.


> For MSDEV all you need to do is put your makefile in it.
>
> Under "Project Settings", "Build Command Line" put for instance:
>
> nmake /C /F "makefile.txt" _DEBUG=1
>
> Then under the same tab there "Output" put your binary image:
>
> MYGAME.GBA

    I will try this, but... will I have to create the makefile? I
guess I am used to the software doing that for me automatically.

> You can use a tool like my "ADSMSGFIX" utility on www.gbadev.org to
format
> the error/warning output to something that MSDEV can handle.

    I'm not quite sure I get this part. If I understand you, the tool
you mention, or a similar one, will monitor the assembly process and
translate error codes and insert them into the text stream of MSVC
progress window?

You can use the Embedded Visual Tools form Microsoft that they have for download
for free in their Windows Mobile Section -
http://www.microsoft.com/downloads/details.aspx?familyid=1DACDB3D-50D1-41B2-A107\
-FA75AE960856&displaylang=en

It's the development environment for the Pocket PC and Smartphone. The compiler
supports full inline assembly so it should let you do whatever it is you're
planning on doing.

Guido Henkel, CEO
G3 Studios - http://www.g3studios.com

--------------------------------------------------------------------------------\
----------------
FLITP IT!  --  CLEOPATRA  --  Get it now!
Our latest games, now available for your Brew cell phone

Try them - http://www.g3studios.com/games
--------------------------------------------------------------------------------\
-----------------

This response and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed.If you are not the intended recipient, you should not
copy it, re-transmit it, use it or disclose its contents, but should
return it to the sender immediately and delete your copy from your
system.

   ----- Original Message -----
   From: Bill DeWitt
   To: gbadev@yahoogroups.com
   Sent: Friday, November 12, 2004 4:36 PM
   Subject: [gbadev] Non-Command line ASM?





      I think I am getting the hang of the basics of assembly, reading
   Pete Cockerell's "ARM Assembly Language Programming", but to assemble
   the programs for testing I would like to use a Windows application
   rather than have to use a command line program in a DOS box. Does
   such a thing exist? Can I use VHAM or MSVC++ to assemble? (I'm pretty
   sure MSVC++ will -not- do it).

      I would also like a app for converting graphics like gfx2gba, but
   in a window so I can choose directories easily and so my bad typing
   won't make me have to retype commands so many times.

      Thanks in advance.

>    I think I am getting the hang of the basics of assembly, reading
> Pete Cockerell's "ARM Assembly Language Programming", but to assemble
> the programs for testing I would like to use a Windows application
> rather than have to use a command line program in a DOS box. Does
> such a thing exist? Can I use VHAM or MSVC++ to assemble? (I'm pretty
> sure MSVC++ will -not- do it).

>    I would also like a app for converting graphics like gfx2gba, but
> in a window so I can choose directories easily and so my bad typing
> won't make me have to retype commands so many times.

The upside of using command-line programs, is that they are easily
incoorporated into a makefile, so all graphics conversions, assembling,
compiling, tweaking etc. is all done automaticaly.

Cheers,
Peter

I think I am getting the hang of the basics of assembly, reading
Pete Cockerell's "ARM Assembly Language Programming", but to assemble
the programs for testing I would like to use a Windows application
rather than have to use a command line program in a DOS box. Does
such a thing exist? Can I use VHAM or MSVC++ to assemble? (I'm pretty
sure MSVC++ will -not- do it).

    I would also like a app for converting graphics like gfx2gba, but
in a window so I can choose directories easily and so my bad typing
won't make me have to retype commands so many times.

    Thanks in advance.

When you are using 256 color Paletted tiles for your
background in say Mode 0,

I know each background,0 - 3, can have it's own set of
tiles, but can each background have it's own palette
as well?

All I can find from my tutorials is that there is only
one background palette to follow, which makes it hard
for me to easily incorperate a bunch of different
layered backgrounds that use different colors without
creating a master background palette.
I'd rather load a certian palette with a certain set
of tiles, but just wondering how to easily do that.


Another thing is that creating those paletted tiles
can be a real pain in the butt at times because when I
transfer the picture into gif form to use the
gifs2sprites program to turn it into gameboy form, I
can't control the way the palette order is.
If I order the palette the way I want it manually  and
I don't know how to manually change the gameboy tile
palette reference numbers without doing the simple,
but annoying number swap and test, swap and test
method with the number references.

So I'm thinking there has to be a better way to manage
creating art stuff for the GBA and have greater
control over the code part of the gif image then
microsoft paint and Adobe photodeluxe allows.

What art software do you all like to use?


Thanks for the help,

Jason






__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com

On Tuesday 09 November 2004 20:50, Bill DeWitt wrote:
>   Can I use my flash device to overwrite old games with my own
> programs? I don't want to waste a cartridge on experiments,
> even though I might never play the game again...

No, flash devices can only write to flash media.  Normal carts
are ROM (read-only memory.)

Rob

Can I use my flash device to overwrite old games with my own
programs? I don't want to waste a cartridge on experiments, even
though I might never play the game again...

--- In gbadev@yahoogroups.com, "Jan-Lieuwe Koopmans" <jan-
lieuwe@e...> wrote:
>
> Hi,
>
> All types of RAM you described are physicaly seperated (they are
accessed
> through different busses). The CPU uses the '0x02', '0x03' (etc.)
to
> determine which chip you want to access. The lower bits will then
be used as
> an offset within the RAM/VRAM/ROM/I.O. registers you selected.


   That makes sense. Why they don't just say that in the tutorials I
can't imagine.... Thanks!

Hi,

All types of RAM you described are physicaly seperated (they are accessed
through different busses). The CPU uses the '0x02', '0x03' (etc.) to
determine which chip you want to access. The lower bits will then be used as
an offset within the RAM/VRAM/ROM/I.O. registers you selected.

Other areas include: System ROM (0x00), Palette RAM (0x05), VRAM (0x06),
Sprite VRAM (0x07), Game ROM/Flash memory (0x08, 0x0A, 0x0C) and Game RAM
(0x0E).

The 32kB of RAM you mentioned (connected to a 32-bit bus) is the fastest
(both for random and sequential access, 1 wait-state). Use it to store 32
bit variables which are frequently used and 32 bit routines (ARM code).

The 256 kB of RAM (connected to a 16-bit bus) is slower than that; both
random and sequential access cost 2 wait-states (per 16 bit chunk). Use it
to store 16 bit variables or 32 bit variables which are not accessed that
often. If required you can also store executable code here (you'll need it
for multiboot for instance), but make sure it's Thumb code (16 bit per
instruction).

For comparison: ROM also uses a 16-bit bus and needs 3 waitstates for random
access. 1 waitstate for sequential access (this can be configured, though).
Note that there's a prefetch buffer available which can speed up the ROM
accesses.

To illustrate the difference:

reading 64 bits of ROM = 3+1+1+1 = 6 waitstates.
reading 64 bits of 32kB RAM = 1+1 = 2 waitstates.
reading 64 bits of 256kB RAM = 2+2+2+2 = 8 waitstates


Greetings,
Jan-Lieuwe

>  I was looking at the memory map of the GBA (as in page two of
>
http://www.ziegler.desaign.de/GBA/gameboy_advance_for_nongaming_applications.pdf\
)
> and I guess I don't understand the convention. For instance:
>
> External 0x02000000  256 KB  16 bits
>
> Internal 0x03000000   32 KB  32 bits
>
> IO Ram   0x04000000    1 KB  32 bits
>
>  Why does there seem to be equal distances between unequal sizes of
> memory? Are the addresses just arbitrary labels? Or do they refer to
> actual locations in the physical memory?

I was looking at the memory map of the GBA (as in page two of
http://www.ziegler.desaign.de/GBA/gameboy_advance_for_nongaming_applications.pdf\
)
and I guess I don't understand the convention. For instance:

External 0x02000000  256 KB  16 bits

Internal 0x03000000   32 KB  32 bits

IO Ram   0x04000000    1 KB  32 bits

   Why does there seem to be equal distances between unequal sizes of
memory? Are the addresses just arbitrary labels? Or do they refer to
actual locations in the physical memory?

You could take a look at http://downtou.cjb.net.

In the GBA section they got a bit on link.
   ----- Original Message -----
   From: Palamon 3
   To: gbadev@yahoogroups.com
   Sent: Saturday, November 06, 2004 9:41 PM
   Subject: Re: [gbadev] Re: Intro and newbie question



   Is there any good tutorials on doing multiplayer
   games, or, dare I say it, using the wireless adaptor,
   and on that note, how to do what a few of the classic
   games can do with the adaptor, which is loading up a
   copy of the game onto another GBA that doesn't have a
   cartridge in it so both can play.




   --- jason rogers <dovoto@...> wrote:

   >
   > These are two tutorials that I like the most:
   > http://user.chem.tue.nl/jakvijn/tonc/
   > www.thepernproject.com
   >
   > I am kindof partial to the pern project being that
   > it is mine but the tonc
   > ones are excelent as well and touch on few things
   > better than I do.  Hope
   > this helps.
   > -jason
   >
   > Jason Rogers
   > aka Dovoto
   > www.ThePernProject.com
   >
   > ----- Original Message -----
   > From: "Bill DeWitt" <Bill@...>
   > To: <gbadev@yahoogroups.com>
   > Sent: Friday, November 05, 2004 4:48 PM
   > Subject: [gbadev] Re: Intro and newbie question
   >
   >
   > >
   > >
   > >
   > >
   > >>     Being that the person in question was
   > concerned that the
   > > upcoming DS
   > >> would render his knowledge obsolete, it seems
   > appropriate not to
   > > use HAM as
   > >> it WILL be obsolete (until it is extended to
   > support the DS which I
   > > expect
   > >> will happen over time); the knowledge gained from
   > writing his own
   > >> functionality would be much more useful in this
   > transition.
   > >
   > >   BTW, I got that.
   > >
   > >> My personal
   > >> thoughts are, that the GBA hardware is easier to
   > learn than the HAM
   > > api
   > >
   > >
   > >  Can you recommend some tutorials? While I
   > appreciate the ease of
   > > premade libraries and will use them shamelessly,
   > in most things I end
   > > up slowly but surely making my own functions to do
   > -exactly- what I
   > > want them to do.
   > >
   > >
   > >
   > >
   > >
   > >
   > >
   > >
   > >
   > >
   > >
   > > Yahoo! Groups Links
   > >
   > >
   > >
   > >
   > >
   > >
   > >
   > >
   >
   >
   >
   >
   >
   >




   __________________________________
   Do you Yahoo!?
   Check out the new Yahoo! Front Page.
   www.yahoo.com






         Yahoo! Groups Sponsor

         Get unlimited calls to

         U.S./Canada




------------------------------------------------------------------------------
   Yahoo! Groups Links

     a.. To visit your group on the web, go to:
     http://groups.yahoo.com/group/gbadev/

     b.. To unsubscribe from this group, send an email to:
     gbadev-unsubscribe@yahoogroups.com

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

hi,

> Is there any good tutorials on doing multiplayer
> games, or, dare I say it, using the wireless adaptor,

> and on that note, how to do what a few of the classic
> games can do with the adaptor, which is loading up a
> copy of the game onto another GBA that doesn't have a
> cartridge in it so both can play.
>

this is known as 'multi-boot'. i've never seen a tutorial which
demonstrates how to use this, but here is some pretty good information
of how you might go about it:

http://www.work.de/nocash/gbatek.htm#biosmultibootsinglegamepak


actually, i just found this demo program:
http://www.devrs.com/gba/files/mbclient.txt

description:

Here's a short GCC demo program to send a small program from one GBA to
another using multiboot. The slave GBA will automatically execute the
program that is sent to it. -- posted by Jeff Frohwein

cheers.
-mike.


>
>
>
> --- jason rogers <dovoto@...> wrote:
>
> >
> > These are two tutorials that I like the most:
> > http://user.chem.tue.nl/jakvijn/tonc/
> > www.thepernproject.com
> >
> > I am kindof partial to the pern project being that
> > it is mine but the tonc
> > ones are excelent as well and touch on few things
> > better than I do.  Hope
> > this helps.
> > -jason
> >
> > Jason Rogers
> > aka Dovoto
> > www.ThePernProject.com
> >
> > ----- Original Message -----
> > From: "Bill DeWitt" <Bill@...>
> > To: <gbadev@yahoogroups.com>
> > Sent: Friday, November 05, 2004 4:48 PM
> > Subject: [gbadev] Re: Intro and newbie question
> >
> >
> > >
> > >
> > >
> > >
> > >>     Being that the person in question was
> > concerned that the
> > > upcoming DS
> > >> would render his knowledge obsolete, it seems
> > appropriate not to
> > > use HAM as
> > >> it WILL be obsolete (until it is extended to
> > support the DS which I
> > > expect
> > >> will happen over time); the knowledge gained from
> > writing his own
> > >> functionality would be much more useful in this
> > transition.
> > >
> > >   BTW, I got that.
> > >
> > >> My personal
> > >> thoughts are, that the GBA hardware is easier to
> > learn than the HAM
> > > api
> > >
> > >
> > >  Can you recommend some tutorials? While I
> > appreciate the ease of
> > > premade libraries and will use them shamelessly,
> > in most things I end
> > > up slowly but surely making my own functions to do
> > -exactly- what I
> > > want them to do.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Check out the new Yahoo! Front Page.
> www.yahoo.com
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
--

Is there any good tutorials on doing multiplayer
games, or, dare I say it, using the wireless adaptor,
and on that note, how to do what a few of the classic
games can do with the adaptor, which is loading up a
copy of the game onto another GBA that doesn't have a
cartridge in it so both can play.




--- jason rogers <dovoto@...> wrote:

>
> These are two tutorials that I like the most:
> http://user.chem.tue.nl/jakvijn/tonc/
> www.thepernproject.com
>
> I am kindof partial to the pern project being that
> it is mine but the tonc
> ones are excelent as well and touch on few things
> better than I do.  Hope
> this helps.
> -jason
>
> Jason Rogers
> aka Dovoto
> www.ThePernProject.com
>
> ----- Original Message -----
> From: "Bill DeWitt" <Bill@...>
> To: <gbadev@yahoogroups.com>
> Sent: Friday, November 05, 2004 4:48 PM
> Subject: [gbadev] Re: Intro and newbie question
>
>
> >
> >
> >
> >
> >>     Being that the person in question was
> concerned that the
> > upcoming DS
> >> would render his knowledge obsolete, it seems
> appropriate not to
> > use HAM as
> >> it WILL be obsolete (until it is extended to
> support the DS which I
> > expect
> >> will happen over time); the knowledge gained from
> writing his own
> >> functionality would be much more useful in this
> transition.
> >
> >   BTW, I got that.
> >
> >> My personal
> >> thoughts are, that the GBA hardware is easier to
> learn than the HAM
> > api
> >
> >
> >  Can you recommend some tutorials? While I
> appreciate the ease of
> > premade libraries and will use them shamelessly,
> in most things I end
> > up slowly but surely making my own functions to do
> -exactly- what I
> > want them to do.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>




__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com

These are two tutorials that I like the most:
http://user.chem.tue.nl/jakvijn/tonc/
www.thepernproject.com

I am kindof partial to the pern project being that it is mine but the tonc
ones are excelent as well and touch on few things better than I do.  Hope
this helps.
-jason

Jason Rogers
aka Dovoto
www.ThePernProject.com

----- Original Message -----
From: "Bill DeWitt" <Bill@...>
To: <gbadev@yahoogroups.com>
Sent: Friday, November 05, 2004 4:48 PM
Subject: [gbadev] Re: Intro and newbie question


>
>
>
>
>>     Being that the person in question was concerned that the
> upcoming DS
>> would render his knowledge obsolete, it seems appropriate not to
> use HAM as
>> it WILL be obsolete (until it is extended to support the DS which I
> expect
>> will happen over time); the knowledge gained from writing his own
>> functionality would be much more useful in this transition.
>
>   BTW, I got that.
>
>> My personal
>> thoughts are, that the GBA hardware is easier to learn than the HAM
> api
>
>
>  Can you recommend some tutorials? While I appreciate the ease of
> premade libraries and will use them shamelessly, in most things I end
> up slowly but surely making my own functions to do -exactly- what I
> want them to do.
>
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

>     Being that the person in question was concerned that the
upcoming DS
> would render his knowledge obsolete, it seems appropriate not to
use HAM as
> it WILL be obsolete (until it is extended to support the DS which I
expect
> will happen over time); the knowledge gained from writing his own
> functionality would be much more useful in this transition.

    BTW, I got that.

> My personal
> thoughts are, that the GBA hardware is easier to learn than the HAM
api


   Can you recommend some tutorials? While I appreciate the ease of
premade libraries and will use them shamelessly, in most things I end
up slowly but surely making my own functions to do -exactly- what I
want them to do.

Thanks for all the responses.

   I got my devkit in the mail today, should be having fun soon.
Already pulling out my hair over stupid programming mistakes...
switching from C to basic to C means typing things as if I knew what
I was doing then having to rewrite everything when it throws an error.

   It's not like I needed something new to make me pull out my hair...

Emanuel,
     I apologize as I seem to be misunderstood.  I was referring only to ham
lib which I believe is a very solid implementation of the functionality
needed to create games and demos.  I applaud HAM lib as it has introduced
many people to consol coding that would otherwise shy away from the
technical details.  It has been great for the scene and one of the main
reasons that developing on the GBA is so popular.  I believe I stated that
if your goal was to create gba games and demos without worry of the details
then embrace HAM.  This was not ment to be sarcastic and if this is not what
you feel the purpose of the HAM lib is then I apologize again.
     Being that the person in question was concerned that the upcoming DS
would render his knowledge obsolete, it seems appropriate not to use HAM as
it WILL be obsolete (until it is extended to support the DS which I expect
will happen over time); the knowledge gained from writing his own
functionality would be much more useful in this transition.  My personal
thoughts are, that the GBA hardware is easier to learn than the HAM api but
that is because I am more accustomed to twiddling bits than interfacing
libraries.  I understand that this is not the case for many users. HAM is a
personal choice that suits many people.
     There are many reasons that HAM is often looked down upon by the people
who have chosen not to use it. It seems that people who use ham have a much
harder time understanding problems that arise in their code because they
don't really grasp what is going on behind the scenes.  Although this is
likely not the case with the majority of HAM users I am sure it is the case
with the majority of the ones asking me questions.  Another less tangible
reason is that the majority of the amatures are coding simply for enjoyment
and HAM feels a bit like cheating. Personally I am not sure what attraction
there is to amatures writing games for GBA in HAM as there are many such
libraries for the PC which are much more powerful.  There is also the fear
of many that HAM is bloated, as any general purpose library must be in order
to remain generic.  I do not know the truth behind this nor do I claim to be
able to write faster code but when the functionality is simple to implement
many coders prefer to implement it themselves.  The final reason that comes
to mind is that if you use a general purpose Library you are locked in to
the way it does things.  Even if its methods are the best around programmers
will still feel confined and frustrated.  To me, a library such as libgba
(off of www.devkit.tk) is a much more satisfying approach as it only
provides that functionality which is tedious to implement without removing
the details or trying to force any structure to my code.
     As to the tool chain I would not recommend ham labs cygwin based tool
chain over the much more capable and often more up to date devkitarm. It is
single click install that is about 5 times smaller than the HAM lib
installer as well as significantly faster in compilation.  I am not sure
what benefit there would be to using the HAM tool chain but would be happy
to hear about it.  I honestly do appreciate HAM even though it is mainly do
to the fact that it draws so many new people to the scene and this is
something I always like to see.  HAM definately has its advantages and just
because it is not to my personal taste I honestly did not mean to talk it
down.  It was meant as a friendly jab at most.
-jason

Jason Rogers
aka Dovoto
www.ThePernProject.com

----- Original Message -----
From: "Emanuel Schleussinger (Ngine.de)" <tubooboo@...>
To: <gbadev@yahoogroups.com>
Sent: Friday, November 05, 2004 1:53 AM
Subject: RE: [gbadev] Intro and newbie question


>
>
> Hi Jason,
>
> While i can understand the fact that you suggest people that want to
> properly learn programming embedded platforms to avoid the HAMlib function
> library, I just don't really get why you and many others discourage people
> from using HAM altogether for GBA development. Essentially, if you do not
> link the HAMlib function code, the system is just as capable as is any
> other
> C/C++ development kit based on GCC -- it just saves you the headaches of
> installing the tool chain and scripts.
>
> I'd be interested to hear why many gbadev@ members still think that HAM is
> not suitable for them and rather build their own toolchains -- many
> professional studios use HAM (without the library) for lowlevel
> development
> without problems, too.
>
> Emanuel
> HAM author
>
>
>> -----Original Message-----
>> From: jason rogers [mailto:dovoto@...]
>> Sent: Freitag, 5. November 2004 01:04
>> To: gbadev@yahoogroups.com
>> Subject: Re: [gbadev] Intro and newbie question
>>
>>
>>
>> Bill,
>>     GBA is probably the best non-pc platform to begin
>> programming on.  It is powerful enough to do some incredible
>> things, yet simple enough to be mastered with out having a
>> huge background in programming.  Couple this with one of the
>> more active online programming communities and you have an
>> unparalleled system to learn on.  As for the DS, if homebrew
>> development is possible on it in the near future you should
>> take comfort in the fact that it has a 2D system that is
>> nearly identical to the GBA (with some subtle and a few not
>> so subtle differences) so your efforts will transfer almost
>> seamlessly to the new platform (and would be required even if
>> you were to start with the DS).  I suspect that if we find
>> means to run code on the DS, much of the GBA community will
>> migrate towards this new system, but as you already made a
>> hardware commitment to the GBA I would stick with it for a while.
>>
>> As for landmines:
>> 1) If you are looking to learn how to write software on a
>> game consol avoid HAM.
>> 2) If you are looking to produce a GBA game/demo without the
>> bother of details, embrace HAM.
>> 3) There are many tutorials and resources for GBA development
>> that should get you off to a good start.
>>     -the docs section on www.gbadev.org should point you to
>> most of them, as will the link section on www.devrs.com
>> 4) If you decide HAM is not for you (a decision I applaud)
>> start with devkitarm from www.devkit.tk as apposed to the
>> outdated devkitadv that many still use.
>> 5) Start simple, read other peoples source code, and ask lots
>> of questions (#gbadev on irc at effnet is a great place).
>> -jason
>>
>> Jason Rogers
>> aka Dovoto
>> www.ThePernProject.com

Hi Jason,

While i can understand the fact that you suggest people that want to
properly learn programming embedded platforms to avoid the HAMlib function
library, I just don't really get why you and many others discourage people
from using HAM altogether for GBA development. Essentially, if you do not
link the HAMlib function code, the system is just as capable as is any other
C/C++ development kit based on GCC -- it just saves you the headaches of
installing the tool chain and scripts.

I'd be interested to hear why many gbadev@ members still think that HAM is
not suitable for them and rather build their own toolchains -- many
professional studios use HAM (without the library) for lowlevel development
without problems, too.

Emanuel
HAM author


> -----Original Message-----
> From: jason rogers [mailto:dovoto@...]
> Sent: Freitag, 5. November 2004 01:04
> To: gbadev@yahoogroups.com
> Subject: Re: [gbadev] Intro and newbie question
>
>
>
> Bill,
>     GBA is probably the best non-pc platform to begin
> programming on.  It is powerful enough to do some incredible
> things, yet simple enough to be mastered with out having a
> huge background in programming.  Couple this with one of the
> more active online programming communities and you have an
> unparalleled system to learn on.  As for the DS, if homebrew
> development is possible on it in the near future you should
> take comfort in the fact that it has a 2D system that is
> nearly identical to the GBA (with some subtle and a few not
> so subtle differences) so your efforts will transfer almost
> seamlessly to the new platform (and would be required even if
> you were to start with the DS).  I suspect that if we find
> means to run code on the DS, much of the GBA community will
> migrate towards this new system, but as you already made a
> hardware commitment to the GBA I would stick with it for a while.
>
> As for landmines:
> 1) If you are looking to learn how to write software on a
> game consol avoid HAM.
> 2) If you are looking to produce a GBA game/demo without the
> bother of details, embrace HAM.
> 3) There are many tutorials and resources for GBA development
> that should get you off to a good start.
>     -the docs section on www.gbadev.org should point you to
> most of them, as will the link section on www.devrs.com
> 4) If you decide HAM is not for you (a decision I applaud)
> start with devkitarm from www.devkit.tk as apposed to the
> outdated devkitadv that many still use.
> 5) Start simple, read other peoples source code, and ask lots
> of questions (#gbadev on irc at effnet is a great place).
> -jason
>
> Jason Rogers
> aka Dovoto
> www.ThePernProject.com
>
> ----- Original Message -----
> From: "Pete Gunter" <reno@...>
> To: <gbadev@yahoogroups.com>
> Sent: Thursday, November 04, 2004 2:41 PM
> Subject: Re: [gbadev] Intro and newbie question
>
>
> >
> >
> > Hi Bill,
> >
> > In my opinion the GBA is a great platform for a hobbyist
> programmer, and
> > a great way to improve your C programming skills.
> >
> > It's completely different to writing games for the PC, as
> there are no
> > complex API's to learn, and it provides a great low-level
> look at games
> > console architecture. There's plenty of information available on the
> > internet, and a highly active community of more than helpfull
> > enthusiasts. Plus as you've got a flash kit coming, you get the
> > satisfaction of seeing your creations runnning on hardware.
> >
> > In short I think GBA development is more than a viable
> hobby, it's quite
> > a fulfilling one too.
> >
> > Regards,
> > -Pete Gunter
> >
> > Bill DeWitt wrote:
> >
> >>
> >>
> >> Hi,
> >>
> >>    My name is Bill and my son just got his first GBA. I have been
> >> doing some programming both in C and some game programming in
> >> DarkBasic, but I am not a programmer by any means.
> >>
> >>    I just wondered if GB proramming was a viable hobby. I see that
> >> some of the tools have not really had much in the way of recent
> >> development, it seems that Visual HAM may be on the back shelf, and
> >> the advent of the DS may even put the whole GBA world in limbo.
> >>
> >>    I sent off for the flash adapter kit and I downloaded some tools
> >> and have been playing around with the emulators, but I
> don't want to
> >> get too far into another field without knowing what
> landmines I might
> >> find.
> >>
> >>    Any conversation on the issue appreciated.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> *Yahoo! Groups Sponsor*
> >> ADVERTISEMENT
> >> click here
> >>
> <http://us.ard.yahoo.com/SIG=129jend45/M=315388.5529724.660208
> 0.3001176/D=groups/S=1705055196:HM/EXP=1099667901/A=2372354/R=
> 0/SIG=12id813k2/*https://www.orchardbank.com/hcs/hcsapplicatio
> n?pf=PLApply&media=EMYHNL40F21004SS>
> >>
> >>
> >>
> >>
> --------------------------------------------------------------
> ----------
> >> *Yahoo! Groups Links*
> >>
> >>     * To visit your group on the web, go to:
> >>       http://groups.yahoo.com/group/gbadev/
> >>
> >>     * To unsubscribe from this group, send an email to:
> >>       gbadev-unsubscribe@yahoogroups.com
> >>
> <mailto:gbadev-unsubscribe@yahoogroups.com?subject=Unsubscribe>
> >>
> >>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> >>       Service <http://docs.yahoo.com/info/terms/>.
> >>
> >>
> >> .
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> --------------------~-->
> Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
> Now with Pop-Up Blocker. Get it for free!
> http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/cPRolB/TM
> --------------------------------------------------------------
> ------~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

Bill,
     GBA is probably the best non-pc platform to begin programming on.  It is
powerful enough to do some incredible things, yet simple enough to be
mastered with out having a huge background in programming.  Couple this with
one of the more active online programming communities and you have an
unparalleled system to learn on.  As for the DS, if homebrew development is
possible on it in the near future you should take comfort in the fact that
it has a 2D system that is nearly identical to the GBA (with some subtle and
a few not so subtle differences) so your efforts will transfer almost
seamlessly to the new platform (and would be required even if you were to
start with the DS).  I suspect that if we find means to run code on the DS,
much of the GBA community will migrate towards this new system, but as you
already made a hardware commitment to the GBA I would stick with it for a
while.

As for landmines:
1) If you are looking to learn how to write software on a game consol avoid
HAM.
2) If you are looking to produce a GBA game/demo without the bother of
details, embrace HAM.
3) There are many tutorials and resources for GBA development that should
get you off to a good start.
     -the docs section on www.gbadev.org should point you to most of them, as
will the link section on www.devrs.com
4) If you decide HAM is not for you (a decision I applaud) start with
devkitarm from www.devkit.tk as apposed to the outdated devkitadv that many
still use.
5) Start simple, read other peoples source code, and ask lots of questions
(#gbadev on irc at effnet is a great place).
-jason

Jason Rogers
aka Dovoto
www.ThePernProject.com

----- Original Message -----
From: "Pete Gunter" <reno@...>
To: <gbadev@yahoogroups.com>
Sent: Thursday, November 04, 2004 2:41 PM
Subject: Re: [gbadev] Intro and newbie question


>
>
> Hi Bill,
>
> In my opinion the GBA is a great platform for a hobbyist programmer, and
> a great way to improve your C programming skills.
>
> It's completely different to writing games for the PC, as there are no
> complex API's to learn, and it provides a great low-level look at games
> console architecture. There's plenty of information available on the
> internet, and a highly active community of more than helpfull
> enthusiasts. Plus as you've got a flash kit coming, you get the
> satisfaction of seeing your creations runnning on hardware.
>
> In short I think GBA development is more than a viable hobby, it's quite
> a fulfilling one too.
>
> Regards,
> -Pete Gunter
>
> Bill DeWitt wrote:
>
>>
>>
>> Hi,
>>
>>    My name is Bill and my son just got his first GBA. I have been
>> doing some programming both in C and some game programming in
>> DarkBasic, but I am not a programmer by any means.
>>
>>    I just wondered if GB proramming was a viable hobby. I see that
>> some of the tools have not really had much in the way of recent
>> development, it seems that Visual HAM may be on the back shelf, and
>> the advent of the DS may even put the whole GBA world in limbo.
>>
>>    I sent off for the flash adapter kit and I downloaded some tools
>> and have been playing around with the emulators, but I don't want to
>> get too far into another field without knowing what landmines I might
>> find.
>>
>>    Any conversation on the issue appreciated.
>>
>>
>>
>>
>>
>>
>>
>> *Yahoo! Groups Sponsor*
>> ADVERTISEMENT
>> click here
>>
<http://us.ard.yahoo.com/SIG=129jend45/M=315388.5529724.6602080.3001176/D=groups\
/S=1705055196:HM/EXP=1099667901/A=2372354/R=0/SIG=12id813k2/*https://www.orchard\
bank.com/hcs/hcsapplication?pf=PLApply&media=EMYHNL40F21004SS>
>>
>>
>>
>> ------------------------------------------------------------------------
>> *Yahoo! Groups Links*
>>
>>     * To visit your group on the web, go to:
>>       http://groups.yahoo.com/group/gbadev/
>>
>>     * To unsubscribe from this group, send an email to:
>>       gbadev-unsubscribe@yahoogroups.com
>>       <mailto:gbadev-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>>
>>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>>       Service <http://docs.yahoo.com/info/terms/>.
>>
>>
>> .
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

Hi Bill,

In my opinion the GBA is a great platform for a hobbyist programmer, and
a great way to improve your C programming skills.

It's completely different to writing games for the PC, as there are no
complex API's to learn, and it provides a great low-level look at games
console architecture. There's plenty of information available on the
internet, and a highly active community of more than helpfull
enthusiasts. Plus as you've got a flash kit coming, you get the
satisfaction of seeing your creations runnning on hardware.

In short I think GBA development is more than a viable hobby, it's quite
a fulfilling one too.

Regards,
-Pete Gunter

Bill DeWitt wrote:

>
>
> Hi,
>
>    My name is Bill and my son just got his first GBA. I have been
> doing some programming both in C and some game programming in
> DarkBasic, but I am not a programmer by any means.
>
>    I just wondered if GB proramming was a viable hobby. I see that
> some of the tools have not really had much in the way of recent
> development, it seems that Visual HAM may be on the back shelf, and
> the advent of the DS may even put the whole GBA world in limbo.
>
>    I sent off for the flash adapter kit and I downloaded some tools
> and have been playing around with the emulators, but I don't want to
> get too far into another field without knowing what landmines I might
> find.
>
>    Any conversation on the issue appreciated.
>
>
>
>
>
>
>
> *Yahoo! Groups Sponsor*
> ADVERTISEMENT
> click here
>
<http://us.ard.yahoo.com/SIG=129jend45/M=315388.5529724.6602080.3001176/D=groups\
/S=1705055196:HM/EXP=1099667901/A=2372354/R=0/SIG=12id813k2/*https://www.orchard\
bank.com/hcs/hcsapplication?pf=PLApply&media=EMYHNL40F21004SS>
>
>
>
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
>
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/gbadev/
>
>     * To unsubscribe from this group, send an email to:
>       gbadev-unsubscribe@yahoogroups.com
>       <mailto:gbadev-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> .