gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Beginners > Where to start and what equipment to get... [Renamed]

#79714 - brandonman - Sat Apr 15, 2006 3:53 pm

Hello, I am just wanting to get into developing for the gba. I am looking for places to get the hardware needed and what else I'll need. Please post link

#79719 - keldon - Sat Apr 15, 2006 4:58 pm

Tonc GBA Tutorials
gbatek reference


cart
MBV2

The MBV2 is a cheaper option that loads your code using multiboot and therefore needs no cart.

#79742 - brandonman - Sat Apr 15, 2006 7:06 pm

thanks...any other links?

#79783 - keldon - Sat Apr 15, 2006 11:57 pm

Check out the beginners FAQ

One question, what is your current experience?[/url]

#79815 - brandonman - Sun Apr 16, 2006 3:24 am

I know the following markup languages,scripts, and programming languages: HTML, DHTML, JAVASCRIPT, a little JAVA, LIBERTY BASIC, a little C, and a little C++

#79816 - tepples - Sun Apr 16, 2006 3:30 am

To get started on the GBA, the only hardware you need are a GBA, a CompactFlash card, a CompactFlash writer, and a GBA Movie Player.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#79850 - keldon - Sun Apr 16, 2006 12:55 pm

brandonman wrote:
I know the following markup languages,scripts, and programming languages: HTML, DHTML, JAVASCRIPT, a little JAVA, LIBERTY BASIC, a little C, and a little C++


You will need to not only learn the languages, but also how to actually program. Various algorithms, programming patterns etc.

#79865 - phoenixj91 - Sun Apr 16, 2006 4:42 pm

You should read up on bitwise operations and hardware registers, they will be a major part in any GBA project.

#79880 - sumiguchi - Sun Apr 16, 2006 6:44 pm

For buying hardware, check the retailer feedback section:
http://forum.gbadev.org/viewforum.php?f=13

Personall I bought the Movie Player and that was fine to start, but I ended up buying a SuperCard SD shortly after... Movie Player can only play Multiboot ROMS which have a limited size & no SRAM to save games/highscores.

#79891 - tepples - Sun Apr 16, 2006 10:29 pm

sumiguchi wrote:
Movie Player can only play Multiboot ROMS which have a limited size & no SRAM to save games/highscores.

A ROM for a traditional GBA flash cart can be up to 32 MB (256 Mbit) and can save up to 64 KB (512 Mbit). GBA Movie Player, on the other hand, allows program+data+save to be up to the size of a CF card.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#80878 - SevenString - Tue Apr 25, 2006 11:45 pm

I'm also a fan of the GBAMP2 (GBA Movie Player, Version 2). You can order one for as little as $15.

As tepples said, all you need is:

1) Your PC
2) CF reader ($10 USB @ OfficeMax)
2) Your GBA
3) GBAMP2
4) CompactFlash card(s) (128K @ $10 each from OfficeMax)
5) DevKitPRO (free download, easy to install)
6) Other freeware libs and sw tools as needed

That's it. You're ready to rock.

Now comes the hard part... actually making a game!!! :D
_________________
"Artificial Intelligence is no match for natural stupidity."

#80908 - gauauu - Wed Apr 26, 2006 2:31 am

Actually, I recommend, if you haven't done any serious dev before, NOT buying anything yet.

Work through the tutorials and some basic programs using just emulators (Download devkitarm and visual boy advance). Most gba emulators are good enough for getting your feet wet.

You'll soon decide whether you're having a blast and want nothing more than to see your creation running on hardware, or whether this whole nonsense is way over your head and not worth the effort.

At that point, if you give up, you haven't wasted some $50-$100 on hardware that you won't use.

But hey, that's just my opinion.

#80952 - sgeos - Wed Apr 26, 2006 8:19 am

gauauu wrote:
Work through the tutorials and some basic programs using just emulators (Download devkitarm and visual boy advance). Most gba emulators are good enough for getting your feet wet.

This is how I got started. I actually "rarely" use my flash cart. I do most testing using software emulators and use hardware for verification. Flashing takes too long.

-Brendan

#80973 - tepples - Wed Apr 26, 2006 1:20 pm

sgeos wrote:
I actually "rarely" use my flash cart. I do most testing using software emulators and use hardware for verification. Flashing takes too long.

So what happens when you start getting into areas of the hardware that public emulators handle urine-poorly, such as the link cable or cycle timing or DS mode?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#80992 - gauauu - Wed Apr 26, 2006 4:36 pm

At that point, you start using actual hardware. Neither one of us suggested that you never use hardware once you get into more serious or heavier development.... especially for situations like that...just that for MOST gba development (And especially entry-level development) emulation works fine.

I'm not recommending brandonman to NEVER buy the hardware...I'm recommending to wait until he goes far enough with development that the expense would actually be worthwhile.

<rant>I know way too many people who decide they want to get into some new hobby (whether dev related, or mountain climbing, or photography, or whatever), so the first thing they do is rush out and buy all the expensive equipment related to the hobby. Then, one month later, they decide they don't really love it after all, and have all this wasted junk sitting around. I'm a strong advocate of using cheap or borrowed or free equipment until you know you really want to invest in your hobby.</rant>

...of course, those people are nice to have as friends, because you can buy all their junk second hand from them at discount prices once they've got a new hobby ;-)

#80997 - SevenString - Wed Apr 26, 2006 5:24 pm

Agreed that if you're just getting started, ESPECIALLY if you don't have any programming experience to speak of, DON'T run out and buy a bunch of equipment.

And yes, for the majority of my GBA or DS dev work, I use emulation.

But when you DO want to see your stuff running on HW, if you already have a CompactFlash card and reader, a $15 GBA Movie Player isn't exactly breaking the bank. ;)

As an added bonus, if even a beginner can see the simplest of his or her programs actually running on a real GBA or DS, that can be quite a motivational tool to keep going and improving.
_________________
"Artificial Intelligence is no match for natural stupidity."

#81014 - tepples - Wed Apr 26, 2006 7:42 pm

SevenString wrote:
And yes, for the majority of my GBA or DS dev work, I use emulation.

So how do you work around the emulator bugs that each new version of the libraries included with devkitARM seems to expose?

Quote:
But when you DO want to see your stuff running on HW, if you already have a CompactFlash card and reader, a $15 GBA Movie Player isn't exactly breaking the bank. ;)

Only for the GBA.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#81022 - SevenString - Wed Apr 26, 2006 8:14 pm

Quote:
So how do you work around the emulator bugs that each new version of the libraries included with devkitARM seems to expose?


I don't update my devkit environment that often, but when I do, if anything breaks in the DS emulator, I already have in place (or set up new) blocks like so:

Code:
#ifdef USING_EMU
... simplified/altered emu code
#else
... real hw code
#endif


This way, I can continue with coding game logic, adding content, and other higher level tasks, and if I need to test on HW, I just comment out #define USING_EMU in my header, rebuild, and go.

On a related note, I don't know if anyone else is doing this, but I've abstracted external data access to a function that looks something like:

Code:
extern void *MyFileGetData(char *filename, int *size);


The actual code of the function first looks for the requested "file" in a linked main GBFS object. If the function doesn't find the data there, it tries to find it using the gba_nds_fat library.

This abstraction allows me to use the same code for testing small chunks of GBFS content on the emulator, as well as when I'm testing larger chunks of dynamically loaded FAT data on HW.

I know Dualis is suppoed to support FAT emulation, but I haven't had any luck getting that to work. Oh well...[/code]
_________________
"Artificial Intelligence is no match for natural stupidity."

#81035 - waruwaru - Wed Apr 26, 2006 9:01 pm

SevenString wrote:
I know Dualis is suppoed to support FAT emulation, but I haven't had any luck getting that to work. Oh well...[/code]


I think there are some bugs in Dualis, so directory structures definitely gets a bit screwed up. If you keep the .nds and all the files you try to access in the same directory, it should be ok.
_________________
DSLua - a scripting language for your DS!

#81038 - SevenString - Wed Apr 26, 2006 9:20 pm

Thanks for the tip... I'll try that. Even though I use a naming convention that insures unique names for every data file, this may be the push I need to switch over to concatenated per-level data files to keep things from getting too messy.
_________________
"Artificial Intelligence is no match for natural stupidity."