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 > Please help set-up a Mac newb!

#38778 - killlerofangels - Thu Mar 31, 2005 6:59 pm

I am having trouble setting-up my computer for GBA development and any info would be greatly appreaciated. Please hear this poor fool's troubles.

I'm using a Mac (OS 10.8) and have recently installed Xcode in an effort to get started on game development. I have been making games for years using QBASIC on my old PC and consider myself a fairly experienced programmer. I bought a book on C/C++ programming and have read and understood the entire thing but the actual set-up of the compiler is something of a mystery to me. I can't get Xcode to compile anything and must resort to the command shell to build my .c files using:
Code:
cc -o whateverApp whatever.c
and that seems to do the trick for my simple text trial apps. I gave up on learning Mac graphics as Apple's developer info assumes you allready know OpenGL and whatnot.

That brings me to the GBA. I understand the concept of writing directly to memory for GBA grafix so the coding wont be the problem. My trouble is every tuturial out there doesn't cover the most basic setup of the GBA devkit or are only PC oriented. I downloaded devkitARM 11 but don't know how to use it for crap. I've now been at this for 3 days and I'm about to go dig the PC out of the trash just to see if I can make any progress. If I can get this working I swear the first thing I'll do is write a tutorial for other newb idiots like me. Can anyone please give me a walkthrough? :*(

#38781 - tepples - Thu Mar 31, 2005 7:10 pm

There is no Mac OS X 10.8. Did you mean 10.3 (Panther)?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#38782 - killlerofangels - Thu Mar 31, 2005 7:16 pm

Oops! 10.3(.8)

#38783 - poslundc - Thu Mar 31, 2005 8:10 pm

killlerofangels wrote:
I gave up on learning Mac graphics as Apple's developer info assumes you allready know OpenGL and whatnot.


Actually, OpenGL isn't at all necessary for Mac graphic programming. Although coding for OS X requires you to pick up a bunch of paradigms, and learn Objective C. The developer tutorials do hold your hand quite well through most of it, though.

Quote:
That brings me to the GBA. I understand the concept of writing directly to memory for GBA grafix so the coding wont be the problem. My trouble is every tuturial out there doesn't cover the most basic setup of the GBA devkit or are only PC oriented. I downloaded devkitARM 11 but don't know how to use it for crap. I've now been at this for 3 days and I'm about to go dig the PC out of the trash just to see if I can make any progress. If I can get this working I swear the first thing I'll do is write a tutorial for other newb idiots like me. Can anyone please give me a walkthrough? :*(


Check out this link: http://gnufoo.org/gbasdk/gbasdk.html

There was another resource like it once but I can't seem to google it up.

For the record, if you are intent on GBA development you WILL eventually get to the point where you'll have to consider using a PC to debug your code, since the Windows emulators are infinitely more useful than their Mac counterparts. I keep a cheap 500 MHz P3 laptop around for mainly this purpose, and it's networked with my Mac so that I'm able to compile on one and debug on the other, all without leaving the laptop.

Dan.

#38788 - killlerofangels - Thu Mar 31, 2005 8:51 pm

poslundc wrote:
OS X requires you to pick up a bunch of paradigms, and learn Objective C.

Yeah... I looked into that. I'll get to it eventually. I was looking more for something simple like a command to plot pixels in a window, not learning a whole subset of the language.

Quote:
Check out this link: http://gnufoo.org/gbasdk/gbasdk.html


I saw that from the other Mac thread. Althought it's pretty step-by-step I ran into a problem allready in the "hello world" part of the tuturial. I emailed the author but that was only an hour ago and I'm so fried at this point I thought I'd post here and see what responses I get.

I think my problem is more with my lack of understanding of the command shell enviornment (and compiling in general). Like I said before, Xcode is too complicated an IDE for what I know of programming but I may have to learn that before I get anything else done. :-(

Oh, and as far as emulators go... If I run into any problems I've allready got a flash cart but I'll keep the PC in mind as a last resort. Thanks for the reply. :-)

#38794 - poslundc - Thu Mar 31, 2005 9:20 pm

killlerofangels wrote:
I think my problem is more with my lack of understanding of the command shell enviornment (and compiling in general). Like I said before, Xcode is too complicated an IDE for what I know of programming but I may have to learn that before I get anything else done. :-(


Unfortunately, you will not get very far in GBA programming without getting decently comfortable with shell interaction. You can get farther in Windows than you can on Mac, but sooner or later you'll have to do some makefile editing, and if you aren't already proficient with the command line tools you'll be screwed at that point.

Quote:
Oh, and as far as emulators go... If I run into any problems I've allready got a flash cart but I'll keep the PC in mind as a last resort. Thanks for the reply. :-)


Running on hardware is not the same as debugging on an emulator. On hardware, it either works or it doesn't, and you can't tell why not if it doesn't. In an emulator such as VBA (Windows version) or NO$GBA you get loads of useful tools to help you figure out why, and in some configurations can even run source-level debuggers to trace a bug to lines in your actual C code while the program is running.

Dan.

#38803 - serf - Thu Mar 31, 2005 10:46 pm

I'm in kind of the same boat. Just this week, I started trying to write code for the GBA on my Powerbook. It's not hard to get it to compile -- it just comes down to making sure you have all the right pieces and then writing a makefile to put them together. Here's what worked for me:

1. Get the devkitARM_r11_OSX, buildscripts, and libgba packages from the devkitPRO page on Sourceforge. Put the devkitARM_r11_OSX and libgba directories wherever you like.

2. Find gbafix.c in the buildscripts directory. Compile it (with Apple's gcc, not devkitARM's arm-elf-gcc, of course) and put the binary in the devkitARM_r11_OSX/bin directory. You can delete buildscripts now if you want -- I don't think there's anything else you need in there right now.

3. Get http://www.mattstanton.com/gba/Makefile.

4. Open up Makefile in your favorite text editor. Edit BINDIR to point to devkitARM_r11_OSX/bin (whereever you put it). LIBDIR and INCDIR are : delimited lists of directories where the compiler will look for library and include files, respectively. Have LIBDIR point to the directory where libgba.a is, and INCDIR point to the libgba include directory.

5. Put the makefile in your project directory. Edit PROJ to be the name of the final product -- i.e., if PROJ is "test", the final product will be "test.gba". Edit OFILES to be the list of all the object files that you want to be linked in. (If you have the C files a.c and b.c, and the assembler file asm.s, OFILES should be "a.o b.o asm.o".)

6. Build your project from the command line with the command "make". (You can delete all .o, .elf, and .gba files with "make clean".)

7. Run your .gba file in an emulator or on hardware.

This may not be the best way to do things, but you should at least be able to compile and run code.

In the long run, though, it looks like you'd be better off taking poslundc's advice. VBA for OS X has no debugging support, and the GBA has no console (for good old printf debugging). If your program doesn't run correctly, you have almost no tools with which to figure out why.

#38816 - tepples - Fri Apr 01, 2005 1:26 am

serf wrote:
VBA for OS X has no debugging support, and the GBA has no console (for good old printf debugging).

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

#38824 - serf - Fri Apr 01, 2005 2:00 am

Ah. Oops. I obviously have no idea what I'm talking about. That's quite helpful. Thanks!

#38988 - killlerofangels - Sat Apr 02, 2005 10:01 pm

First thanks for the detailed reply. I got a lot further than before but I'm still having a problem. Here's where I get stuck:
serf wrote:
5. Put the makefile in your project directory. Edit PROJ to be the name of the final product -- i.e., if PROJ is "test", the final product will be "test.gba". Edit OFILES to be the list of all the object files that you want to be linked in. (If you have the C files a.c and b.c, and the assembler file asm.s, OFILES should be "a.o b.o asm.o".)

I must be the dummest C programmer ever. All I have is my "test.c" file. I know how to compile .c files to an executable for my Mac that runs in the terminal. Of course this isn't the gba sources but how do I get the a.o, asm.o, etc.? I've only made single .c files before that didn't need to be linked or anything. Is there maybe a good source package I can download that has a sample of all the makefile related stuff too? This is the first time I've ever made a makefile. That's where I ran into the problem with the Socrates tuturial also.

#39000 - poslundc - Sun Apr 03, 2005 1:32 am

The .o extension stands for object file. An object file contains the contents of a .c file after it has been translated from C into the assembled machine code for the target platform (eg. ARM7 on the GBA, or PowerPC on your Mac).

You may have one .o file in a project (such as with your test.c program) or hundreds. In order for them to become an executable program, though, they need to be linked. This is the stage that glues the various functions together, so if you used printf() in your C code, at the linking stage it will actually bind that printf() call to a function reference in the standard libraries.

When you compile your test.c program on the Mac it generates a test.o object file, but it does it transparently to you.

A typical makefile will break the phases up into compiling (generating the .o file) and linking (combining the .o files into the finished product) so that if your program has multiple .c files and you only change one of them, you only need to recompile the .o file for the one that changed, and can reuse the old .o files for all of the other ones.

So, on the OFILES like of your particular makefile you'll want to list the names of your various C files (even if you only have one) with the .o extension, so the makefile knows what to look for (and subsequently create if it doesn't find).

Makefiles are complicated, ugly beasts even for experienced programmers. The best thing to do is to get as much practice as possible using and editing them... I recall Lord Graga also once posted an extremely sexy makefile example, so you might want to search the forum for it.

Dan.

#39038 - killlerofangels - Sun Apr 03, 2005 5:26 pm

Cool. That was very informative. You guys kick ass!

I actually just read the other Mac thread on using the SDK in Xcode and it worked first try so screw the makefile. Still, it's good to know that stuff. Thanks again for your help.

#39044 - poslundc - Sun Apr 03, 2005 7:34 pm

killlerofangels wrote:
I actually just read the other Mac thread on using the SDK in Xcode and it worked first try so screw the makefile.


Haha... wait.

Dan.

#39049 - killlerofangels - Sun Apr 03, 2005 9:48 pm

poslundc wrote:
I recall Lord Graga also once posted an extremely sexy makefile example, so you might want to search the forum for it.


If anyone was interested, I found the thread.
http://forum.gbadev.org/viewtopic.php?t=3991

And yes... The GBA SDK I got had me excited for a sec because it actually built directly in Xcode but I'm starting to get the hang of makefiles to use DevkitARM11 (because it's more current). If only I knew a little more about how to make projects templates in Xcode I'd write one for it. I'll be about 1/2 for GBA development and 1/2 for getting an EASY development enviornment tuturial set-up for OS X. I'm still getting the hang of things so don't hold your breath for the results of either. I promise I'll post as the results come in though. ;-)

#39050 - jstart - Sun Apr 03, 2005 9:56 pm

ooooh cool ill be waiting!