#38300 - brucesinner - Fri Mar 25, 2005 4:09 pm
GBA Development with Eclipse IDE HOWTO - Last Update: 18/07/2006
Ok, to get a nice GBA development environment only using free tools we'll need to setup a few things manually.
So I prepared this small how-to to help beginners like I was, to get programming the GBA more fast without spending hours (like I did) trying to figure out what to do.
The tools chosen here were: Eclipse Development IDE, DevkitARM as gcc toolchain, MSYS to provide us a full POSIX environment with rm and make commands, Visual Boy Advance SDL as GBA emulator and ARM targeted GDB as debug tool.
So let's start, follow these steps carefully:
1) First, go to www.eclipse.org and download latest stable version (in the moment of writing this tutorial, the version was 3.01)
2) Now we need a Eclipse plugin to be able to work with C/C++ on it. The plugin name is CDT and can be obtained here: www.eclipse.org/cdt. check the downloads page and get the update URL there, open Eclipse, go to Help->Software Updates->Find and Install and in the next screen, choose 'Search for new features to install'. click 'New Remote site..." and put the CDT Update URL you've got on CDT download site. Check the modules to install and click next until it download and install automatically. After CDT is installed, lets open the C/C++ perspective in Eclipse. This way, Eclipse will be C/C++ friendly providing us with all options we need like debug, build, make targets, ...Go to Window->Open Perspective->Other... and find C/C++ in the list. Select it and click OK. If you did correctly, the IDE windows will change position and you'll be able to see C/C++ Projects tab to your left side.
3) We need a compiler. Not just an ordinary GCC, but one targeted to ARM plataform. There is some cool distributions around but I think DevKitARM is the best since it's being regularly updated. Go to the DevKitARM site on Sourceforge to grab the latest one.
http://www.sf.net/projects/devkitpro
Unzip it to a directory (i use c:\devkitarm) and put its c:\devkitarm\bin path to the PATH variable. The compiler executable is arm-elf-gcc.exe [note] devkitARM r19+ is arm-eabi-gcc.exe.
4) Now that we did a basic setup of the environment, let's download the emulator. We chose Visual Boy Advance because it has nice debug features which will greatly help us later. Go to Visual Boy Advance site on Sourceforge (www.sf.net/projects/vba) and download the VBA 1.7 SDL version. ATTENTION! DO NOT DOWNLOAD NEWER VERSIONS THAN 1.7, they're all BROKEN and will not debug correctly. For emulation purposes, they are ok, though. devkitPro.org also provides a suitable windows build of VBA SDL 1.7.1 at http://www.devkitpro.org/downloads.shtml
5) Unzip the emulator somewhere on your hard disk (i did it in c:\vba, just change for the folder you like). Now open Eclipse and let's set it as External Tool we'll be using to test our ROMs. Open Run->External Tools->External Tools... In the left list box click on 'Program' and on the 'New' button at the list bottom. In the Main tab, go to the Name input box at top of the screen and write "Visual Boy Advance Run". Now go to the Location option, browse to the folder you unzipped VBA and choose the VBA executable. On Arguments option, put '${project_loc}\${project_name}.gba' (without the quotes). This way we are telling VBA to start the GBA ROM we generated informing it using Eclipse internal variables ${project_loc} (project location) and ${project_name} (project name). Switch to Common tab and unmark 'Launch in background' checkbox. Next, go to Run->External Tools->Organize Favorites... Click Add.. and select the program you just added. Now it will appear on the Eclipse toolbar, under the green play icon with a red lock.
6) We need a POSIX environment to be able to clean our compiled objects (delete .o files with rm command) and to make our makefile. We are luck since there is a nice project called MSYS which provides a full POSIX environment for WIN32. It can be obtained at
http://prdownloads.sourceforge.net/mingw/MSYS-1.0.10.exe?download
Download the executable file and install it. If you did the default installation you will have it installed at c:\msys\1.0. Just put in your PATH variable the c:\msys\1.0\bin folder. DON'T FORGET THIS STEP. Without it we will not be able to make our project.
7)Now that we have the basics to program, let's start a new project and import a makefile into it. Go to File->New->Project..., select C++/Standard Makefile C++ Project. Type a name for it and press 'Finish'. A new folder under the Eclipse workspace will be created. Now go to File->New->File. Type makefile for its name. As the objective of this how-to is not teach makefiles, just copy-paste the makefile below, which is a very simple one. Just replace the PROJ name in Project Details section and put your project name.
| Code: |
#
# test.mak
#
# makefile for a simple demo
# --- Project details ---
PROJ := test
EXT := gba
CFILES := main.cpp
COBJS := $(CFILES:.cpp=.o)
OBJS := $(COBJS)
#--- Tool settings ---
# for devkitARM r19+ use PREFIX := arm-eabi
PREFIX := arm-elf-
AS := $(PREFIX)as
CC := $(PREFIX)gcc
LD := $(PREFIX)gcc
OBJCOPY := $(PREFIX)objcopy
MODEL := -mthumb-interwork -mthumb
SPECS := -specs=gba.specs # comment out for DKA
ASFLAGS := -mthumb-interwork
CFLAGS := -I./ $(MODEL) -O2 -Wall
LDFLAGS := $(SPECS) $(MODEL)
#--- Build steps ---
build : $(PROJ).$(EXT)
$(PROJ).$(EXT) : $(PROJ).elf
@$(OBJCOPY) -v -O binary $< $@
-@gbafix $@
$(PROJ).elf : $(OBJS)
@$(LD) $(OBJS) $(LDFLAGS) -o $@
$(COBJS) : %.o : %.cpp
$(CC) $(CFLAGS) -g -c $< -o $@
# --- Clean ---
.PHONY : clean
clean :
@rm -fv $(COBJS)
@rm -fv $(PROJ).$(EXT)
@rm -fv $(PROJ).elf
|
Notice the ARM specific settings in link parameters. They are a must. Also some people complained of errors like "missing separator" when they cut and paste this makefile from the post. Makefiles have some restrict rules like having a TAB at the beginning of an indented line. Just put it there and you're done.
We need to change the default make executable to the one provided with MSYSdistribution. Open Project->Properties, select C/C++ Make Project on the list and unmark 'Use Default' on Build Command group. Type there: make -f makefile
Now we need to create a CPP file which will hold our simple GBA example.
Go to File->New->Source File and type 'main.cpp'. Now cut and paste the code below (a simple example that draws a pixel on middle of GBA screen)
| Code: |
int main(void)
{
// create a pointer to the video buffer
unsigned short* videoBuffer = (unsigned short*)0x6000000;
// switch to video mode 3 (240x160 16-bit)
// by setting a memory register to a specific value
*(unsigned long*)0x4000000 = (0x3 | 0x400);
// draw a white pixels (16 bits) directly to video memory
// pixel location is centered on the screen (120,80)
videoBuffer[80 * 240 + 120] = 0xFFFF;
// continuous loop
while(1) {
}
// end program
return 0;
} |
Now it's time to build it and test the resulting stuff on VBA.
We need to create some 'make targets' to be able to build it. Open the make targets view (Window->Show View->Make targets) and right-click your project name. Click on 'Add Make Target'. We will be creating three make targets for our little project. In next screen type 'build' on both Target Name and Make Target. Repeat the process but type 'clean' and 'clean build' The last one is like a rebuild target, so you can put 'rebuild' in Target Name if you wish (i do that). So, let's finally build our project. Double click the make target name you want to build. If things went ok, you should now have a ELF file and a GBA ROM file.
Let's test it on VBA. Click on 'Visual Boy Advance Run' option under the toolbar 'Run External Tools' icon (the one with a green play and a red lock icon)
VBA should now pop-up with our ROM already running. We finished compiling and running our first ROM!!! It's a day to be remembered :)
If you need to Clean your project or Rebuild it, just double-click these targets on the 'Make Target' view.
As a final note, you can import your existing projects with the File->Import... option.
8) At this point you may asking yourselves "How the hell I'll debug it ?". Right, we can't do a development project without debugging it. Remember VBA ? Yes, it has debug capabilities. Nice huhn? Together with GDB we will be able to debug our game as we play it ! Awesome! Let's set it as a External Tool. We'll be using it to debug together with GDB. Open Run->External Tools->External Tools... In the left list box click on 'Program' and on the 'New' button at the list bottom. In the Main tab, go to the Name input box at top of the screen and write "Visual Boy Advance Debug". Now go to the Location option, browse to the folder you unzipped VBA and choose the VB executable. On Arguments option, put '-Gtcp ${project_loc}\${project_name}.elf' (without the quotes). This way we are telling VBA to run in TCP mode (to connect to the debugger) and we are passing the project path and name as parameter, so the emulator loads the ELF file to be debugged. Why use ELF file instead of GBA ROM ? Because GBA rom does not have the debugging information we need.
Now let's setup the GDB part. First change to Debug Perspective. (Window->Open Perspective->Debug). Open Run->Debug... Under C/C++ Local Application create a new configuration pressing the 'Add' button. Give a name to this configuration and in Main tab put the name of the project and select the ELF file in C/C++ Application input (test.elf for example). witch to the Debugger tab and change the combobox to GDB Server. It is very important since we will be doing remote debug between GDB and VBA. Change the connection to TCP and port to 55555 ( the port that VBA uses). In the GDB debugger and GDB command line inputs we need to specify an ARM targeted GDB. When i was writing this tutorial, i couldn't find one since VBA official site was down and that was the only place i knew where existed a Windows compiled version targeted to ARM plataform. So I was directed to insight Debugger. This package contains arm-eabi-gdb
http://sourceforge.net/project/showfiles.php?group_id=114505&package_id=146412
Uncompress it to a folder, and put the full path to arm-eabi-gdb.exe in the two inputs on Debugger tab. All ready, let's debug.
9) To debug the ROM, first run the VBA Debug, the external tool. Nothing should happen but a open process will appear in the debug view on upperleft corner of the IDE. Then you should run the debug configuration you created, under the 'bug' icon on the toolbar. If things go well, the debug configuration will connect through TCP with VBA and stop at the main() function. Now you can set your breakpoints, add expressions, watch variables and so on. Note that you global variables do not appear on the variables window, you must add a expression to see them. F5 and F6 steps through your code and will be your best friend from here on :)
IMPORTANT NOTICE: While debugging stop all downloads, p2p programs and the like. As the debugging process is done by TCP protocol, these things will slow down the process. You have been warned.
Well I think that I explained in details all the process needed to setup Eclipse to make it a full GBA development Environment. Comments will be welcome and if it is needed I'll do any corrections that may follow as people start to use this how-to and discover any missing step :P
Hope you enjoy using Eclipse as I enjoyed, cya in the forums !
Regards
Bruce Sinner
PS: If moderators want, you have the permission to make it as sticky or even, put in the FAQS. When my personal site is up, I'll put it there so you can link it too in Articles section of the main gbadev homepage.[/url]
Last edited by brucesinner on Tue Dec 13, 2005 9:46 pm; edited 7 times in total
#38318 - NoMis - Fri Mar 25, 2005 11:19 pm
Nice work.
NoMis
#38348 - wintermute - Sat Mar 26, 2005 3:32 pm
mingw-make is not recommended for a number of reasons. I've always recommended msys not least because it provides a good unix style environment without the overhead of cygwin. You can also maintain makefiles that are portable across linux, win32 and OSX.
http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download
the gdb archive you've provided isn't complete and is also cygwin dependent. One of the main philosphies behing devkitARM is that it doesn't <censored> use <censored> cygwin :P
http://sourceforge.net/project/showfiles.php?group_id=114505&package_id=146412
use arm-elf-gdb with the -nw switch if you don't want the Insight GUI
#38355 - brucesinner - Sat Mar 26, 2005 4:11 pm
| wintermute wrote: |
| mingw-make is not recommended for a number of reasons. I've always recommended msys not least because it provides a good unix style environment without the overhead of cygwin. You can also maintain makefiles that are portable across linux, win32 and OSX. |
Well mingw32-make just work fine for me. What problems it may gives me ? Either mingw or msys installed is just for the make command. MSYS has rm command in it ? It would be a good reason to swap, as for now I have to put del command to clean my objs.
Well this package i made works great too. I ripped insight from my package since its not necessary and would make no difference for Eclipse use. I would love to get rid of the cygwin dlls too, if your Insight build does not have it would be great. I will download and test it and if it's okay, change the tutorial.
EDIT: Downloaded! The powerpc-elf-gdb is suitable for GCN programming ?
Thanks for the tips wintermute, thats why I love forums ! :)
Regards
Bruce Sinner
#38362 - wintermute - Sat Mar 26, 2005 6:30 pm
| brucesinner wrote: |
| wintermute wrote: | | mingw-make is not recommended for a number of reasons. I've always recommended msys not least because it provides a good unix style environment without the overhead of cygwin. You can also maintain makefiles that are portable across linux, win32 and OSX. |
Well mingw32-make just work fine for me. What problems it may gives me ? Either mingw or msys installed is just for the make command. MSYS has rm command in it ? It would be a good reason to swap, as for now I have to put del command to clean my objs.
|
Yes, msys has rm command. It has a complete bash shell in fact :)
#38928 - yaustar - Sat Apr 02, 2005 3:06 am
| Quote: |
| Unzip it to a directory (i use c:\devkitarm) and put its c:\devkitarm\bin path to the PATH variable. The compiler executable is arm-elf-gcc.exe. |
I cant seem to find the PATH variable to change..
_________________
[Blog] [Portfolio]
#38930 - tepples - Sat Apr 02, 2005 3:48 am
To set up (assuming win2k or winxp):
| Code: |
notepad c:\windows\system32\dkarm.bat
set PATH=c:\devkitarm\bin;%PATH%
File > Save
File > Exit
|
Then whenever you start a command prompt:
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#38941 - brucesinner - Sat Apr 02, 2005 5:02 am
To permanently set-up it,
1) Right-click "My Computer" icon on your desktop (or in start menu) abd click 'Properties'
2) Select the 'Advanced' tab and then click 'Environment Variables' button.
3) On the group 'System Variables', scroll down till you find the PATH variable.
4) Click on it and then click button 'Edit'.
5) Add what you want.
6) Click 'Ok' till you get out of this screen.
Now your PATH should be changed.
Any questions, just ask ;-)
regards
#38943 - ScottLininger - Sat Apr 02, 2005 5:09 am
Tepples....
Might this be added to the FAQ? It Rocks.
-Scott
#38958 - yaustar - Sat Apr 02, 2005 1:41 pm
Thanks however I get the following warning when building:
| Code: |
| Error launching external scanner info generator (gcc -E -P -v -dD E:/Eclipse/Eclipse Workspaces/.metadata/.plugins/org.eclipse.cdt.make.core/specs.cpp) |
And this when trying to run the emu:
| Code: |
VisualBoyAdvance-SDL version 1.7
Windows version
Seaching for file VisualBoyAdvance.cfg
Searching current dir: E:\Eclipse
Searching user profile directory: C:\Documents and Settings\Wacky
Searching executable directory
Reading configuration file.
Unknown file type E:\Eclipse\Eclipse |
Edit: Error was caused by a space in the path to the Workspaces...
_________________
[Blog] [Portfolio]
#39007 - brucesinner - Sun Apr 03, 2005 2:43 am
Unfortunately Eclipse dont understand well 'spaces'
Stick with good ol' DOS style and put everything in a 8-letter directory preferably.
[]s
Bruce
#39075 - NoMis - Mon Apr 04, 2005 8:38 am
| yaustar wrote: |
Thanks however I get the following warning when building:
| Code: | | Error launching external scanner info generator (gcc -E -P -v -dD E:/Eclipse/Eclipse Workspaces/.metadata/.plugins/org.eclipse.cdt.make.core/specs.cpp) |
And this when trying to run the emu:
| Code: | VisualBoyAdvance-SDL version 1.7
Windows version
Seaching for file VisualBoyAdvance.cfg
Searching current dir: E:\Eclipse
Searching user profile directory: C:\Documents and Settings\Wacky
Searching executable directory
Reading configuration file.
Unknown file type E:\Eclipse\Eclipse |
Edit: Error was caused by a space in the path to the Workspaces... |
Spaces aren't a problem with debuging but you have tho put the Arguments into quotes
-Gtcp "${project_loc}\${project_name}.elf"
#39284 - Ethos - Wed Apr 06, 2005 11:52 pm
lol, also have to d/l java sdk :)
#39285 - Ethos - Wed Apr 06, 2005 11:58 pm
| yaustar wrote: |
Thanks however I get the following warning when building:
| Code: | | Error launching external scanner info generator (gcc -E -P -v -dD E:/Eclipse/Eclipse Workspaces/.metadata/.plugins/org.eclipse.cdt.make.core/specs.cpp) |
|
I believe this can be fixed in the Properties, Right click the project and go to Properties, and there should be something under Builders tab. Don't deselect the Makefile one, just the other one.
Btw, I have successfully used eclipse to create NDS roms.
#39287 - brucesinner - Thu Apr 07, 2005 12:27 am
| Ethos wrote: |
| Btw, I have successfully used eclipse to create NDS roms. |
Really ? How to configure ? Just like GBA ?
Well, both use same compiler and stuff, there should be no problem.
Good info man!
#39437 - yaustar - Fri Apr 08, 2005 10:00 pm
I seem to have trouble with the debugging side of things.
I start debugging and the server is suspended.. I have added breakpoints but they dont seem to work.. F5 or F6 doesnt step through the code/run to next breakpoint nor do the expressions work... Have I missed an importent step?..
_________________
[Blog] [Portfolio]
#41486 - odubtaig - Fri Apr 29, 2005 12:50 am
NOTE: I haven't tested this yet, it's late and I'm tired, but i've got arm-elf-gdb and it executes (whether it works as it should is TBC); any constructive criticism, comments, mistakes pointed out will be noted.
...just 'cause I had a helluva time finding anything useful.
Yep, just about every here is available precompiled from the same places but there are a few acute differences such as adding the arm-elf-gcc path and the lack of a precompiled version of gdb suited to cross-compiling for the GBA.
Firstly, if you ever hope to do development for your Linux platform, you'll need to keep everything seperate and some of the development tools may rely on later versions of certain tools (like Eclipse) than your distribution provides so keeping everything in a directory within your home directory is a good plan.
So, in short (all command line from hereon in):
The instructions for Eclipse are the same, just
unzip exclipse-SDK-x.x.x-linux-gtk.zip
cd eclipse
and
./eclipse
to run and then you can get updates from the URL on the website.
Downloading devkitATM is the same, drop it in your GBA development directory and
tar jxvf devkitARM_r11-linux.tar.bz2
to extract.
Set the path everytime you log in by editing .profile in your home directory, I use vim to do this but kate will be more friendly for those not initiated in the ways of vi or vim so
kate ~/.profile
and add the line
export PATH=$PATH:/home/<yourloginnamehere>/<GBAdevdirectory>/devkitARM_r11/bin
This won't actually take effect until you next log in. This means exiting you login session in X windows and re-logging in then as XTerm/konsole sessions don't count.
VisualBoy advance can also be downloaded for Linux (lucky us :o) ) from here which should run on any modern Linux distro. You will, however have to make a new directory for this or it'll extract where everything else is so
mkdir vba
cd vba
tar zxvf ../VisualBoyAdvance-1.7-SDL-linux-glibc22.tar.gz
OK, now we can entirely skip the POSIX environment bit as we already have one of those so onto GDB which is a tad trickier but not overly cumbersome.
So... get the latest version of the gdb source from http://ftp.gnu.org/gnu/gdb/. Note that there is no ARM specific version as the source code is for all platforms including for cross-compiling and won't be specific until we compile it.
Now, if you don't have them already installed (and you should do if you're going to compile anything) you'll be needing -- as a bare minimum -- gcc, gcc-g++, libgcc, binutils, make, automake and if I've missed anything off this list could someone let me know.
You will also probably need insight to be installed (there should be one with your distribution). As it is, I had no problems compiling gdk but then I tend to install absolutely everything so no wonder there.
For this compile, we'll be wanting to install this version of gdb somewhere other than where the version of gdb for standard debugging resides, a good place to put this would be in the devkitARM directory.
So
./configure --target=arm-elf --prefix=/home/<yourloginnamehere>/<GBAdevdirectory>/devkitARM_r11/
(all one line)
make install
After all the text scrolls past (ignore warnings, some are normal, it's errors that are the problem) everything should be nicely set up.
regards, Paul
Last edited by odubtaig on Fri Apr 29, 2005 3:57 pm; edited 1 time in total
#41545 - odubtaig - Fri Apr 29, 2005 3:56 pm
1), the arguments line for VisualBoy Advance should be
${project_loc}/${project_name}.gba
and not
${project_loc}\${project_name}.gba
(see if you can spot the difference :op ).
2) The --build= option is not actually necessary when configuring gdb for the platform you plan to run it on as, unlike some configure scripts, it checks this itself. This will be updated.
3) Eclipse does not necessarily auto-save all files when a build is called (although a rebuild does call up a dialog); if you're getting errors you think you've fixed, check all files are saved/unmodified.
4) This now all works on my system, any problems you have are therefore not because I've done something wrong but either because my instructions are unclear (in which case I apologise) or because you've done something wrong (in which case I don't). If you have any problems (errors, dependencies, whatever). Search the forums and the internet properly before asking anby questions.
#43000 - SevenString - Wed May 18, 2005 12:03 am
Wow, this is cool, Bruce! Thanks!
I've been experimenting with different configurations of Visual Studio, HAM, VisualHam, DevKitARM, etc.
But I haven't been happy with any of the combos as a long term solution. I finally came to the conclusion that Eclipse and DevKitARM is the non-compromise way to go, and this thread helped me to get it set up very quickly. And I'm starting to really dig it!
Nice work!
_________________
"Artificial Intelligence is no match for natural stupidity."
#43002 - wintermute - Wed May 18, 2005 12:17 am
of course, had you dug around a bit more you might have found this
http://sourceforge.net/project/showfiles.php?group_id=114505&package_id=146412
which is a self-extracting exe containing arm-elf-gdb :)
it includes the Insight gui but you can use the -nw switch on the command line to get plain vanilla gdb.
I've been attempting to get a later version of Insight to build natively for windows ( and obviously the corresponding later version of gdb) but have met with a number of problems. I may just give in soon & just compile gdb itself.
#43045 - SevenString - Wed May 18, 2005 5:10 pm
Hey Wintermute,
Thanks! I know that was directed at someone else, but I hadn't gotten around to setting up my debugger yet. That link you provided was very timely for me.
_________________
"Artificial Intelligence is no match for natural stupidity."
#43050 - ymalik - Wed May 18, 2005 6:05 pm
Brucesinner, the following link does not work:
http://www.sinnerfx.com.br/files/gba/ARM_gdb.rar
Could you please upload a ZIPed or GZIPed version? I don't have a RAR decompressor.
Thanks,
Yasir
#44112 - Dark Knight ez - Mon May 30, 2005 2:11 pm
When trying to build (double click the "build" Make Target), I get the following error:
Error launching builder (make -f makefile build )
(Exec error:Launching failed)
I've followed all your steps so far though. Including setting the PATH variable and such and creating and saving your "makefile" file. I don't think I've missed anything. Any idea what could be wrong?
#44115 - NoMis - Mon May 30, 2005 2:57 pm
This error occours if eclipse could not launch the make command. Most of the time this is because eclipse can't find make so you may double check your path variable.
You can also try to run the make command manually in the command prompt and see what error you get.
NoMis
#44116 - Dark Knight ez - Mon May 30, 2005 3:10 pm
It worked via the command prompt.
After opening Eclipse once more, there were no issues left. It probably checks the PATH variable at startup of the program. I feel rather dumb for not having tried that out first. Thanks for your help.
I now have the following error though... could you help me out?
make -f makefile build
makefile:39: warning: overriding commands for target `Test_GBA'
makefile:35: warning: ignoring old commands for target `Test_GBA'
arm-elf- gcc -I./ -mthumb-interwork -mthumb -O2 -Wall -g -c main.cpp -o main.o
make: arm-elf-: Command not found
make: *** [main.o] Error 127
#44398 - Cearn - Wed Jun 01, 2005 9:29 am
| Dark Knight ez wrote: |
It worked via the command prompt.
After opening Eclipse once more, there were no issues left. It probably checks the PATH variable at startup of the program. I feel rather dumb for not having tried that out first. Thanks for your help.
I now have the following error though... could you help me out?
make -f makefile build
makefile:39: warning: overriding commands for target `Test_GBA'
makefile:35: warning: ignoring old commands for target `Test_GBA'
arm-elf- gcc -I./ -mthumb-interwork -mthumb -O2 -Wall -g -c main.cpp -o main.o
make: arm-elf-: Command not found
make: *** [main.o] Error 127 |
'arm-elf- gcc' isn't a command, and 'gcc' isn't a commandline option. 'arm-elf-gcc' is. (There's a space that shouldn't be there.)
#44405 - Dark Knight ez - Wed Jun 01, 2005 1:21 pm
Thank you. Removing the space worked. :)
#44453 - linus - Wed Jun 01, 2005 11:02 pm
Thanks so much for this, i got the test working fine but now im trying to use the gba includes given in dovotos tutorial http://www.drunkencoders.com/tutorials/GBA/day_1.html ive put the im in the devKitArm/include and devKitArm/arm-elf/include ive modified the given makefile as follows:
| Code: |
#
# test.mak
#
# makefile for a simple demo
# --- Path settings ---
DEVDIR := C:\Linus\Dev\ARM\devkitARM
LIBDIR := $(DEVDIR)\arm-elf\lib\interwork
LIBDIR2 := $(DEVDIR)\libgba\lib
INCDIR := $(DEVDIR)\arm-elf\include
INCDIR2 := $(DEVDIR)\include
# --- Project details ---
PROJ := test2
EXT := gba
CFILES := test2.cpp
COBJS := $(CFILES:.cpp=.o)
OBJS := $(COBJS)
#--- Tool settings ---
PREFIX := arm-elf-
AS := $(PREFIX)as
CC := $(PREFIX)gcc
LD := $(PREFIX)gcc
OBJCOPY := $(PREFIX)objcopy
MODEL := -mthumb-interwork -mthumb
SPECS := -specs=gba.specs # comment out for DKA
ASFLAGS := -mthumb-interwork
CFLAGS := -I./ -I$(INCDIR) -I$(INCDIR2) $(MODEL) -O2 -Wall
LDFLAGS := $(SPECS) $(MODEL) -L$(LIBDIR) -L$(LIBDIR2)
#--- Build steps ---
build : $(PROJ).$(EXT)
$(PROJ).$(EXT) : $(PROJ).elf
@$(OBJCOPY) -v -O binary $< $@
-@gbafix $@
$(PROJ).elf : $(OBJS)
@$(LD) $(OBJS) $(LDFLAGS) -o $@
$(COBJS) : %.o : %.cpp
$(CC) $(CFLAGS) -g -c $< -o $@
# --- Clean ---
.PHONY : clean
clean :
@rm -fv $(COBJS)
@rm -fv $(PROJ).$(EXT)
@rm -fv $(PROJ).elf
|
but when i #include <gba.h> i get a no such file or directory error. This is my first attept at even modifying a makefile so im sorry if im being a bit of a spanner.
Cheers,
Linus
EDIT: lol sorry about this post i got it working but as i thought i was being a spanner. Changing \ to / fixes the problem :)
#44702 - Dark Knight ez - Sat Jun 04, 2005 1:25 pm
I built the program, and now all I get is a white screen, which after a while turns into a black screen. I doubt that's supposed to happen (since the description of the program reads that only the center pixel should be white). Any idea what causes this and how this can be resolved?
Also, could you note in the tutorial that project names containing an underscore won't work? I've spend quite a while to figure that out. ;)
#44722 - wintermute - Sat Jun 04, 2005 4:48 pm
| Dark Knight ez wrote: |
I built the program, and now all I get is a white screen, which after a while turns into a black screen. I doubt that's supposed to happen (since the description of the program reads that only the center pixel should be white). Any idea what causes this and how this can be resolved?
|
http://forum.gbadev.org/viewtopic.php?t=5790
| Quote: |
Also, could you note in the tutorial that project names containing an underscore won't work? I've spend quite a while to figure that out. ;) |
project names containing an underscore should work just fine, spaces won't.
#44726 - Dark Knight ez - Sat Jun 04, 2005 5:39 pm
I probably deleted the space after the project name, after renaming it, in that case.
| Quote: |
| http://forum.gbadev.org/viewtopic.php?t=5790 |
Meaning I have to be patient (either that, or modify and build devkitARM)? I've waited 5 minutes for the white pixel to be displayed, wouldn't that suffice?
#44992 - leafo - Tue Jun 07, 2005 2:40 am
I am new to this, I just followed all the directions up to the part where you first compile and I get this error message
| Code: |
make -f Makefile build
arm-elf-gcc -I./ -mthumb-interwork -mthumb -O2 -Wall -g -c main.cpp -o main.o
process_begin: CreateProcess((null), arm-elf-gcc -I./ -mthumb-interwork -mthumb -O2 -Wall -g -c main.cpp -o main.o, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [main.o] Error 2 |
I dont know how to read these error messages so I dont know what file it is saying is missing.
#45040 - NoMis - Tue Jun 07, 2005 8:22 am
| leafo wrote: |
I am new to this, I just followed all the directions up to the part where you first compile and I get this error message
| Code: | make -f Makefile build
arm-elf-gcc -I./ -mthumb-interwork -mthumb -O2 -Wall -g -c main.cpp -o main.o
process_begin: CreateProcess((null), arm-elf-gcc -I./ -mthumb-interwork -mthumb -O2 -Wall -g -c main.cpp -o main.o, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [main.o] Error 2 |
I dont know how to read these error messages so I dont know what file it is saying is missing. |
He can't find your compiler arm-elf-gcc.
The createprocess tells you that make tries to start something, in this case arm-elf-gcc, but it doesn't succeded. If some of the sourcefiles are missing you would get an error from your compiler.
You may check the path environment variable. It should include the bin folder of your dev kit.
NoMis
#45056 - leafo - Tue Jun 07, 2005 11:56 am
I checked in the bin file, and all the files are there. And I am sure I set it to path. Could it be anything else. I dont have a make.o file, does that matter.
#45490 - jokker - Sat Jun 11, 2005 5:24 am
Hello all,
I got everything running pretty much except for the debugging part (thanks to brucesinner for that great howto)
I can get VBA running waiting for a connection however when I try to use eclipse to connect to it, it just kills the VBA process and comes to an end for seemingly no reason...I checked over the settings and everything appears to be exactly as it should both with regards to the information posted here and my own logical conclusions....I know that using the insight GUI works ok if I connect to the VBA process with that but I would like to try and get this eclipse debugger working...it's a very nice suite.
using Eclipse 3.1, CDT 3.0.1-M6, VBA-SDL 1.7.2, XP, and using the arm-thumb-elf-gdb.exe from HAMlib 2.8
VisualBoyAdvance version 1.7.2 [SDL]
Searching for file VisualBoyAdvance.cfg
Searching current directory: C:\Documents and Settings\Administrator.RETESTRAK.000\Desktop\eclipse
Searching user profile directory: C:\Documents and Settings\Administrator.RETESTRAK.000
Searching executable directory
Reading configuration file.
Parsing debug info
Searching for file vba-over.ini
Searching current directory: C:\Documents and Settings\Administrator.RETESTRAK.000\Desktop\eclipse
Searching user profile directory: C:\Documents and Settings\Administrator.RETESTRAK.000
Searching executable directory
vba-over.ini NOT FOUND (using emulator settings)
Listening for a connection at port 55555
Got a connection from 127.0.0.1 1390
Color depth: 32
Shutting down
Closing remote socket
Closing listen socket
Thanks in advance
_jokker
_________________
Pepsi it's the choice of a GNU generation
#45551 - linus - Sat Jun 11, 2005 11:18 pm
| Quote: |
ATTENTION! DO NOT DOWNLOAD NEWER VERSIONS THAN 1.7, they're all BROKEN and will not debug correctly. For emulation purposes, they are ok, though.
|
#45572 - Crs - Sun Jun 12, 2005 2:54 am
Hello,
Thank you for a nice tutorial, unfortunately I seem to have hit a problem. I have followed the tutorial many times now and the same problem occurs each time:
Console Output:
| Code: |
make -f makefile build
MAKE Version 5.2 Copyright (c) 1987, 2000 Borland
Error makefile 35: Colon expected
Error makefile 36: Command syntax error
Error makefile 37: Command syntax error
Error makefile 39: Colon expected
Error makefile 40: Command syntax error
Error makefile 43: Command syntax error
*** 6 errors during make ***
|
I added the colon as it asks to the end of the lines 35 & 39.. (shouldnt really need to ask its a copy from a working sample?) but the error remains on the blank line 43?
My makefile is a direct copy & paste of this tutorial.
My knowledge of makefiles in non-existant, but if its a copy from the example then it shouldnt fail?
oh, also in the "problems" tab I get the message:
| Code: |
Error launching external scanner info generator (gcc -E -P -v -dD F:/GBADev/eclipse/workspace/.metadata/.plugins/org.eclipse.cdt.make.core/specs.cpp)
|
Sorry I have no idea where I am going wrong, I havent missed anything that I can tell. My paths are in the PATH variable.
Any suggestions what I can try next?
Thank you.
CRS.
#45574 - Crs - Sun Jun 12, 2005 3:10 am
funny how I just solved my own problem.. the MAKE.exe was being called from my Borland Builder path of MAKE, and not the MSYS path
grr that took me hours to solve :(
anyway.. hope that this post can help someone else having had the same issues as me
#45575 - wintermute - Sun Jun 12, 2005 3:12 am
you're running Borland make rather than gnu make. There are two ways around this, rename Borland make or make sure that your msys bin folder is earlier in the path than the Borland bin folder.
#45581 - jokker - Sun Jun 12, 2005 5:56 am
| linus wrote: |
| Quote: | ATTENTION! DO NOT DOWNLOAD NEWER VERSIONS THAN 1.7, they're all BROKEN and will not debug correctly. For emulation purposes, they are ok, though.
|
|
I tried using 1.7 and still the same problem occurs....it's very odd
_________________
Pepsi it's the choice of a GNU generation
#45592 - Crs - Sun Jun 12, 2005 11:38 am
That was well spotted Wintermute, I put the path at the start to solve it :)
However I do still get this warning message in the "Problems" window:
| Code: |
1 Error launching external scanner info generator (gcc -E -P -v -dD F:/GBADev/eclipse/workspace/.metadata/.plugins/org.eclipse.cdt.make.core/specs.cpp) Sample 12 June 2005 11:34:45
|
Is it anything to worry about?
-----
Also, Im not quite sure how to debug with it. (I downloaded version 1.7)
I run the VBA debug tool, run the debug.. it appears to have hit the main function but when I stepover nothing happens? and the VBA display wont appear either... its at the bottom of the taskbar but wont appear on screen even if I click it.
I even put a test "if" condition in the program but step over just doesnt seem to do anything
Anyone else having difficulties debugging?
#45642 - NoMis - Mon Jun 13, 2005 7:32 am
| jokker wrote: |
| I tried using 1.7 and still the same problem occurs....it's very odd |
I don't think that the newest VBA Version is the problem. I already used the newest version of VBA without any trouble.
Unfortunatly I have no idea whats going wrong there. VBA disconnects as soon as he got a connection. Does the eclipse workspace report any errors from the debugger.
You should check the debuggers console output and the eclipse problems view.
NoMis
#45789 - doomlord_uk - Tue Jun 14, 2005 11:12 pm
Thanks for the setup guide :) This was pretty handy because I was looking for an IDE, nevermind the other stuff.
I'm new to all of this and I know I've got lots of reading to do on everything... but I have a question...
Your link to your gdb.rar file, brucesinner, is not showing the file? are you still hosting it? I'm trying to find a host for the HAM kit but the site for that is returning a 404 too... so, I tried the InsightGDB kit and installed that but I notice that the exe is arm-gdb and not arm-elf-gdb... is this going to matter?
I'm getting an 'unknown protocol error' at the mo:
| Code: |
| Unknown protocol tcpC:\Programming\GBA\Eclipse\eclipse\workspace\MyFirstProject\MyFirstProject.elf |
I don't know yet if that's related?
Also, if I may be frank, your instructions would be a LOT easier to read if you put them as bullet points, in a list. I know I'm new to all of this but it took a long time to carefully read through it all and pick out the mistakes I made. That said, I'm glad you went to the trouble, because I'd prolly still be faffing about finding an emulator and IDE to work with...
#45910 - linus - Thu Jun 16, 2005 2:17 pm
Hi everyone ive been trying to load in a picture file to gba program without much success. Im using darkfaders bin2o tool and have actually managed to get the file included in the rom (judging by the file size anyway) using the following makefile (its a bit crap, i still havent got the hang of em)
| Code: |
# --- Path settings ---
DEVDIR := C:/Linus/Dev/ARM/devkitARM
LIBDIR := $(DEVDIR)/arm-elf/lib/interwork
LIBDIR2 := $(DEVDIR)/libgba/lib
INCDIR := $(DEVDIR)/arm-elf/include
INCDIR2 := $(DEVDIR)/include
# --- Project details ---
PROJ := image
EXT := gba
PROJDIR := C:/Linus/Dev/Code/GBA/Workspace/$(PROJ)
PICDIR := $(PROJDIR)/data
CFILES := image.cpp
PFILES := test.pcx
COBJS := $(CFILES:.cpp=.o)
POBJS := $(PFILES:.pcx=.o)
OBJS := $(COBJS)
#--- Tool settings ---
PREFIX := arm-elf-
AS := $(PREFIX)as
CC := $(PREFIX)gcc
LD := $(PREFIX)gcc
OBJCOPY := $(PREFIX)objcopy
BIN2O := bin2o
MODEL := -mthumb-interwork -mthumb
SPECS := -specs=gba.specs # comment out for DKA
ASFLAGS := -mthumb-interwork
CFLAGS := -I./ -I$(INCDIR) -I$(INCDIR2) $(MODEL) -O2 -Wall
LDFLAGS := $(SPECS) $(MODEL) -L$(LIBDIR) -L$(LIBDIR2)
#--- Build steps ---
build : $(PROJ).$(EXT)
$(PROJ).$(EXT) : $(PROJ).elf
@$(OBJCOPY) -v -O binary $< $@
-@gbafix $@
$(PROJ).elf : $(OBJS) $(POBJS)
@$(LD) $(OBJS) $(POBJS) $(LDFLAGS) -o $@
$(POBJS) : $(PFILES)
$(BIN2O) $(PFILES) $(POBJS) !test
$(COBJS) : %.o : %.cpp
$(CC) $(CFLAGS) -g -c $< -o $@
|
but whenever i try to access the data like so...
| Code: |
extern unsigned char test[];
int main(void)
{
unsigned char monk = test[0];
...
|
i get and undefined reference to test, ps i know this doesnt do anything im just trying to get the data. actually that just worked, wierd but something like this doesnt:
| Code: |
int main(void)
{
unsigned char monk = test[0];
monk++;
SetMode(monk);
// end program
return 0;
}
|
#48827 - Habeeb1000 - Fri Jul 22, 2005 8:34 pm
I'm brand new to homebrew programming, but I thought I'd give GBA development a try. I've set up my development environment in Eclipse, and everything seems to work properly, except for using the GDB for debugging. I run VBA SDL 1.7 and connect to it properly with the GDB program, as far as I can tell (I've tried the ones included with the HAM 2.8 and Insight 5.2.1 with similar results), but when either GDB program runs the "info threads" command I either get "No frame." as the response or "warning: RMT ERROR : failed to get remote thread list," depending on which GDB program I use.
It seems similar to what yaustar describes, but no one directly addresses his problem or he never says if he corrects it somehow. I?ve tried different versions of VBA SDL, but I get the same results. I have the impression that something is wrong with the .elf file, but I don?t know what it could be. Here are all of my files for one of the tutorials from Dovoto.
I'm using Eclipse SDK 3.1.0 with CDT 2.1.1 and DevkitARM r14 running on Windows XP. If I'm leaving out any other details let me know.
#48832 - NoMis - Fri Jul 22, 2005 10:11 pm
DevKitARM r14 causes a lot of problems with debugging. I had code that debugged flawlessly on r8 but as I switched to r14 nothing worked anymore.
It doesn't find most of the symbols. Breakpoints in some functions are working and others not. Sometimes it just hangs up completly and I have to kill the process.
Unfortunatly I'm a totall noob if it comes to the technics that work behind the scene, so I have no Idea what causes the problems. r8 worked so well with debugging.
NoMis
_________________
www.gamedev.at - The austrian gamedev site
hde.gamedev.at - The Handheld Dev Env plugins for Eclipse
#48851 - Habeeb1000 - Sat Jul 23, 2005 3:18 am
I switched over to DevkitARM r8 and used Insight's GDB and it works now. I've been banging my head against the wall trying to figure this out. Thank you, NoMis.
#50638 - NighTiger - Thu Aug 11, 2005 8:36 am
Hi guys,
I did try to download http://www.sinnerfx.com.br/files/gba/ARM_gdb.rar
but the url doesn't exist... sigh I need a good IDE to develop gba demo on Linux...
#63513 - brucesinner - Tue Dec 13, 2005 9:44 pm
For whom is experimenting slow down on debugging stuff, just remember that I said not to be running process that take up TCP port or make TCP calls ?
I was using emule at the time i was making this tutorial and I faced a huge slow down on my debugging process. Just double check all your process to make sure you are not running any TCP related stuff.
For the gdb files i was hosting, they are not there any longer. Just use this url instead:
http://sourceforge.net/project/showfiles.php?group_id=114505&package_id=146412
Download Insight Debugger and use the -nw option to avoid entering the GUI. Works the same as the one I was providing.
regards,
#63516 - wintermute - Tue Dec 13, 2005 10:16 pm
I take it you missed this one then?
http://sourceforge.net/project/showfiles.php?group_id=114505&package_id=150769
No more problems with recent devkitARM, also includes gdb binary.
Was announced at http://www.devkitpro.org/index.php?action=fullnews&id=90 on November 19th
Last edited by wintermute on Wed Dec 14, 2005 1:14 pm; edited 1 time in total
#63539 - brucesinner - Wed Dec 14, 2005 2:55 am
I was out of the gba scene for a whiel, i missed that.
Thanks for pointing out wintermule!!!
regards
#63564 - NoMis - Wed Dec 14, 2005 9:28 am
btw. you don't even need to use the -nw option. It does not come up with the UI if you use it with eclipse.
NoMis
_________________
www.gamedev.at - The austrian gamedev site
hde.gamedev.at - The Handheld Dev Env plugins for Eclipse
#67701 - encryptedcode - Thu Jan 19, 2006 11:27 pm
i have some problem,i couldnt olve them
| Code: |
| Error launching external scanner info generator (gcc -E -P -v -dD I:/eclipse_workspace/.metadata/.plugins/org.eclipse.cdt.make.core/specs.cpp) |
and | Code: |
*** No rule to make target `makefile'. Stop |
i sove this
but now there are more errors like this | Code: |
make -f gba_make build
gba_make:36: warning: overriding commands for target `test'
gba_make:33: warning: ignoring old commands for target `test'
arm-elf- gcc -I./ -mthumb-interwork -mthumb -O2 -Wall -g -c main.cpp -o main.o
make: arm-elf-: Command not found
make: *** [main.o] Error 127 |
when i press run visual boy,there exist an error
| Code: |
| reference to undefined variable I |
how can i solve them thanks,and i dont understand why dont we define gcc compiler to eclipse,how can eclipse find our arm compiler,with path variable?
#92538 - Amablue - Thu Jul 13, 2006 9:04 pm
I'm having trouble getting eclipse working with this. I'd like to use eclipse for this since its what I use at school for my Java programming.
I downloaded the C/C++ stuff from the remote site, and installed it in eclipse fine. But when I go to the Window > Open Perspective > Other and choose C/C++. This is where I have trouble. The view on the left of the screen gives me this:
Unable to create view: An unexpected exception was thrown.
Details >>
Does anyone know why I'm getting this?
EDIT: Nevermind me. It's fixed.
#98270 - biubid_boy - Mon Aug 14, 2006 12:08 pm
Sorry for resurecting but...
I have followed this tutorial as closley as I can, and when I run build, I get an error:
| Code: |
c:\devkitarm\arm-eabi\bin\ld.real.exe: error: no memory region specified for loadable section `.ARM.extab'
collect2: ld returned 1 exit status
|
Any idea on how to fix it?
#98284 - wintermute - Mon Aug 14, 2006 1:13 pm
#100805 - Harakiri - Wed Aug 30, 2006 8:22 pm
For those who are interested - this is an updated guide as of 30/08/2006
by me - originally taken from the first post by brucesinner and only edited to reflect changes. Many steps are not needed anymore for example setup msys, download insight debugger, manually add cdt update url etc.. also alot of eclipse labels / steps are now different. I hope this updated guide helps people - i exactly did as described below using eclipse 3.2 and devkitPro Updater 1.3.5.
1) First, go to www.eclipse.org and download latest stable version (in the moment of writing this tutorial, the version was 3.2)
2) Now we need a Eclipse plugin to be able to work with C/C++ on it. The plugin name is CDT. Open Eclipse, go to Help->Software Updates->Find and Install and in the next screen, choose 'Search for new features to install'. Select the "Calisto Discovery Site" and hit Finish. Select one mirror (doesnt matter which) - for example "Calisto Discovery Site". Check the C/C++ modules to install and click next until it download and install automatically. After CDT is installed, lets open the C/C++ perspective in Eclipse. This way, Eclipse will be C/C++ friendly providing us with all options we need like debug, build, make targets, ...Go to Window->Open Perspective->Other... and find C/C++ in the list. Select it and click OK. If you did correctly, the IDE windows will change position and you'll be able to see C/C++ Projects tab to your left side.
3) We need a compiler. Not just an ordinary GCC, but one targeted to ARM plataform. There is some cool distributions around but I think DevKitARM is the best since it's being regularly updated. Go to the DevKitPro site to grab the latest devkitPro Updater - it not only includes DevKitARM and a remote debugger (insight) but also the POSIX environment MSYS which you will need to make (build) your projects.
http://www.devkitpro.org/
Install it to a directory (i use c:\devkitPro and put its c:\devkitPro\devkitarm\bin path to the PATH variable. The compiler executable is arm-eabi-gcc.exe.
4) Now that we did a basic setup of the environment, let's download the emulator. We chose Visual Boy Advance because it has nice debug features which will greatly help us later. Go to Visual Boy Advance site on Sourceforge (www.sf.net/projects/vba) and download the VBA 1.7 SDL version. ATTENTION! DO NOT DOWNLOAD NEWER VERSIONS THAN 1.7, they're all BROKEN and will not debug correctly. For emulation purposes, they are ok, though. devkitPro.org also provides a suitable windows build of VBA SDL 1.7.1 at http://www.devkitpro.org/downloads.shtml
5) Unzip the emulator somewhere on your hard disk (i did it in c:\vba, just change for the folder you like). Now open Eclipse and let's set it as External Tool we'll be using to test our ROMs. Open Run->External Tools->External Tools... In the left list box click on 'Program' and right click on it to select the 'New' Option In the Main tab, go to the Name input box at top of the screen and write "Visual Boy Advance Run". Now go to the Location option, browse to the folder you unzipped VBA and choose the VBA executable. On Arguments option, put '${project_loc}\${project_name}.gba' (without the quotes). This way we are telling VBA to start the GBA ROM we generated informing it using Eclipse internal variables ${project_loc} (project location) and ${project_name} (project name). Switch to Common tab and unmark 'Launch in background' checkbox. Click "Apply" and "Close" to close this window.
Next, go to the Menu Run->External Tools->Organize Favorites... Click Add.. and select the program you just added. Now it will appear on the Eclipse toolbar, under the green play icon with a red lock.
6)Now that we have the basics to program, let's start a new project and import a makefile into it. Go to File->New->Project..., select C++/Standard Makefile C++ Project. Type a name for it (for example 'NDSHelloWorld') and press 'Finish'. A new folder under the Eclipse workspace will be created. Right click this folder and select New->File. Type makefile for its name. As the objective of this how-to is not teach makefiles, just copy-paste the makefile below, which is a very simple one. Just replace the PROJ name in Project Details section and put your project name.
| Code: |
#
# test.mak
#
# makefile for a simple demo
# --- Project details ---
PROJ := NDSHelloWorld
EXT := gba
CFILES := main.cpp
COBJS := $(CFILES:.cpp=.o)
OBJS := $(COBJS)
#--- Tool settings ---
PREFIX := arm-eabi-
AS := $(PREFIX)as
CC := $(PREFIX)gcc
LD := $(PREFIX)gcc
OBJCOPY := $(PREFIX)objcopy
MODEL := -mthumb-interwork -mthumb
SPECS := -specs=gba.specs # comment out for DKA
ASFLAGS := -mthumb-interwork
CFLAGS := -I./ $(MODEL) -O2 -Wall
LDFLAGS := $(SPECS) $(MODEL)
#--- Build steps ---
build : $(PROJ).$(EXT)
$(PROJ).$(EXT) : $(PROJ).elf
@$(OBJCOPY) -v -O binary $< $@
-@gbafix $@
$(PROJ).elf : $(OBJS)
@$(LD) $(OBJS) $(LDFLAGS) -o $@
$(COBJS) : %.o : %.cpp
$(CC) $(CFLAGS) -g -c $< -o $@
# --- Clean ---
.PHONY : clean
clean :
@rm -fv $(COBJS)
@rm -fv $(PROJ).$(EXT)
@rm -fv $(PROJ).elf
|
Notice the ARM specific settings in link parameters. They are a must. Also some people complained of errors like "missing separator" when they cut and paste this makefile from the post. Makefiles have some restrict rules like having a TAB at the beginning of an indented line. Just put it there and you're done.
We need to change the default make executable to the one provided with MSYSdistribution (which is included in the DevKitPro Updater - NOTE: it should automatically set itself as a PATH member - if not do it manually). Right click your Project Folder, select Properties, select C/C++ Make Project on the list and unmark 'Use Default' on Build Command group. Type there: make -f makefile
Now we need to create a CPP file which will hold our simple GBA example.
Right click your Project folder, select New->Source File and type 'main.cpp' without the quotes. Now cut and paste the code below (a simple example that draws a pixel on middle of GBA screen)
| Code: |
int main(void)
{
// create a pointer to the video buffer
unsigned short* videoBuffer = (unsigned short*)0x6000000;
// switch to video mode 3 (240x160 16-bit)
// by setting a memory register to a specific value
*(unsigned long*)0x4000000 = (0x3 | 0x400);
// draw a white pixels (16 bits) directly to video memory
// pixel location is centered on the screen (120,80)
videoBuffer[80 * 240 + 120] = 0xFFFF;
// continuous loop
while(1) {
}
// end program
return 0;
}
|
Now it's time to build it and test the resulting stuff on VBA.
We need to create some 'make targets' to be able to build it. Open the make targets view (Window->Show View->Make targets) and right-click your project name. Click on 'Add Make Target'. We will be creating three make targets for our little project.
First make (build) target
In screen type 'build' (without the quotes) on both Target Name and Make Target instead of 'all'.
Second make (clean) target
In screen type 'build' (without the quotes) type 'clean' for Target Name and 'clean build' for Make Target instead of 'all'.
Third make (rebuild) target
In screen type 'build' (without the quotes) type 'rebuild' for Target Name and 'rebuild' for Make Target instead of 'all'.
So, let's finally build our project. Expand your Project Folder in the 'Make Targets' View. Double click the make target name you want to build. If things went ok, you should now have a ELF file and a GBA ROM file.
The output should like this :
| Code: |
make -f makefile build
arm-eabi-gcc -I./ -mthumb-interwork -mthumb -O2 -Wall -g -c main.cpp -o main.o
copy from `NDSHelloWorld.elf' [elf32-littlearm] to `NDSHelloWorld.gba' [binary]
ROM fixed!
|
Let's test it on VBA. Select your created gba File within your project, Click on 'Visual Boy Advance Run' option under the toolbar 'Run External Tools' icon (the one with a green play and a red lock icon).
VBA should now pop-up with our ROM already running. We finished compiling and running our first ROM!!! It's a day to be remembered :)
If you need to Clean your project or Rebuild it, just double-click these targets on the 'Make Target' view.
As a final note, you can import your existing projects with the File->Import... option.
7) At this point you may asking yourselves "How the hell I'll debug it ?". Right, we can't do a development project without debugging it. Remember VBA ? Yes, it has debug capabilities. Nice huhn? Together with GDB we will be able to debug our game as we play it ! Awesome! Let's set it as a External Tool. We'll be using it to debug together with GDB. Open Run->External Tools->External Tools... In the left list box click on 'Program' , right click on it and select 'New' . In the Main tab, go to the Name input box at top of the screen and write "Visual Boy Advance Debug". Now go to the Location option, browse to the folder you unzipped VBA and choose the VB executable. On Arguments option, put '-Gtcp ${project_loc}\${project_name}.elf' (without the quotes) and click Apply and then Close. This way we are telling VBA to run in TCP mode (to connect to the debugger) and we are passing the project path and name as parameter, so the emulator loads the ELF file to be debugged. Why use ELF file instead of GBA ROM ? Because GBA rom does not have the debugging information we need.
Now let's setup the GDB part. First change to Debug Perspective. (Window->Open Perspective->Debug). Open Run->Debug... Under C/C++ Local Application create a new configuration by right clicking on it an selecting 'New'. Give a name to this configuration and in Main tab put the name of the project and select the ELF file in C/C++ Application input (test.elf for example) using "Search Project".
Switch to the Debugger tab and change the combobox to gdbserver Debugger. In the GDB debugger and GDB command line inputs we need to specify an ARM targeted GDB. The "insight Debugger" is included within the devkitPro Updater. Put the full path to arm-eabi-gdb.exe in the GDB Debuger field (Example : c:\devkitPro\insight\bin\arm-eabi-gdb.exe.)
Finally it is very important since we will be doing remote debug between GDB and VBA to setup the connection. Click on the Connection Tab and select TCP as Type and enter 55555 as Port( the port that VBA uses).
Click Apply and then Close...
Ok, everything is ready, let's debug.
8)Add the VBA Debug you just created as a favorite.
Go to the Menu Run->External Tools->Organize Favorites... Click Add.. and select the program you just added. Now it will appear on the Eclipse toolbar, under the green play icon with a red lock.
To debug the ROM, first run the VBA Debug, the external tool. Nothing should happen but a open process will appear in the debug view on upperleft corner of the IDE. (Note if you have a firewall be sure to grant access to the process!). Then you should run the debug configuration you created, under the 'bug' icon on the toolbar. Select the bug icon - click on "Organize Favorites" and click on add - select your debug configuration. It should now appear in the list under the bug icon.
If things go well, the debug configuration will connect through TCP with VBA and stop at the main() function. Now you can set your breakpoints, add expressions, watch variables and so on. Note that you global variables do not appear on the variables window, you must add a expression to see them. F5 and F6 steps through your code and will be your best friend from here on :)
IMPORTANT NOTICE: While debugging stop all downloads, p2p programs and the like. As the debugging process is done by TCP protocol, these things will slow down the process. You have been warned.
#100810 - gmiller - Wed Aug 30, 2006 8:58 pm
| Quote: |
) Now that we did a basic setup of the environment, let's download the emulator. We chose Visual Boy Advance because it has nice debug features which will greatly help us later. Go to Visual Boy Advance site on Sourceforge (www.sf.net/projects/vba) and download the VBA 1.7 SDL version. ATTENTION! DO NOT DOWNLOAD NEWER VERSIONS THAN 1.7, they're all BROKEN and will not debug correctly. For emulation purposes, they are ok, though. devkitPro.org also provides a suitable windows build of VBA SDL 1.7.1 at http://www.devkitpro.org/downloads.shtml
|
Just for a FYI I have fixed the 1.8 version so it works with the debugger. Should you want the fixed version for windows or the sourcecode I can post a URL. On windows I compiled it with Visual Studio 2005 so there are some runtime DLL's that are need but are in a separate install from Microsoft. Let me know ...
#103529 - madmax - Fri Sep 22, 2006 5:09 pm
It's great you have Eclipse working with the gba dev chain. However I'd like to air on the side of caution. I've used it before for gba development but I am in the process of finding another IDE. My main problem with Eclipse for gba development is that the CDT C++ plugin is no way near mature enough to be usefull. Half the time code complete will just refuse to work for valid code that I'm typing. But it has no other usefull functions like the Eclipse Java engine has such as automatic import resolution. It's main plus point are the debugger interface and the makefile generation. Well the debugger interface is good, when it works. But the makefile generation which is the feather in the CDT cap dosn't really work for the gba dev toolchain.
I'm a linux user myself and most of the IDEs support standard makefiles so I'm going to see if theres something out there that is more mature than eclipse. Even something with a window that lists the header of the object I'm currently working with would be so much more usefull.
_________________
John Noon
#106769 - Ant6n - Mon Oct 23, 2006 7:57 am
Well, I would like to hear if you found anything more useful than eclipse, Madmax (esp. debugging and makefile would be great).
Until then ill try eclipse. So far things are pretty cool, but I too have problems with the debug feature. i use vba 1.7.1 and eclipse 3.1 and i get everything to compile and even debug. When i debug i can step through the code (like i would in jave), and its a little jumpier than in java, but pretty usable nevertheless. I can also press the resume button whereupon i can see my prog running in vba.
BUT while i step through the code vba is frozen (meaning i cant look at the gameboy), and after i pressed resume and look at vba the breakpoints seem to be getting ignored (i.e. i had a breakpoint in the function that gets called when i move player left, but it never breaks even when it does move left).
Does anybody have ideas what might be wrong (or am i dealing with "features")?
anton
#110057 - supudo - Sat Nov 25, 2006 2:53 am
First of all i wish to say hello to all the members of gbadev.org
Second a big thanks to brucesinner for this excellent guide for setting-up gba development environment. I was wondering through a countless sites for a whole week to find a decent IDE to start experimenting (i'm using MS Visual Studio in my day job, so guess how spoiled i am).
To the point... i stuck for about some time on a little problem caused by the Eclipse - "source not found". Finally it turns out that the directory mappings in the editor were wrong (or missing to be more precise). I'm using WinXP so there is a slight difference between cygwin paths and windows paths.
To solve the problem : open Window -> Preferences...; expand C/C++, than expand Debug and select Common Source Lookup Path. Than add a mapping to your projects directory according to this thread.
Just skip the "/cygdrive/c/" part. So for example my mapping is :
Compilation path: \Software
Local file system path: D:\Software
Remember - NO "/cygdrive/" in the path.
P.S. I'm using Eclipse 3.2.1 on Windows XP.
_________________
[shtruc]
Last edited by supudo on Sat Nov 25, 2006 3:14 pm; edited 1 time in total
#110080 - gmiller - Sat Nov 25, 2006 6:39 am
I gave up on eclipse because of the component conflict issues. If you have Visual Studio 2005 (any edition) then the make file projects can be set up to work with the devKitARM toolchain. VS 2003 has broken makefile project support so I would not use that. Since I no longer use eclipse there is little I can do to address those issues. I hope someone can help you there.
The VS 2005 along with the sed utility is all you need to get a working makefile environment using the MS IDE.
#110154 - elmro - Sun Nov 26, 2006 2:02 am
[quote]8)Add the VBA Debug you just created as a favorite.
Go to the Menu Run->External Tools->Organize Favorites... Click Add.. and select the program you just added. Now it will appear on the Eclipse toolbar, under the green play icon with a red lock.
To debug the ROM, first run the VBA Debug, the external tool. Nothing should happen but a open process will appear in the debug view on upperleft corner of the IDE. (Note if you have a firewall be sure to grant access to the process!). Then you should run the debug configuration you created, under the 'bug' icon on the toolbar. Select the bug icon - click on "Organize Favorites" and click on add - select your debug configuration. It should now appear in the list under the bug icon.
If things go well, the debug configuration will connect through TCP with VBA and stop at the main() function. Now you can set your breakpoints, add expressions, watch variables and so on. Note that you global variables do not appear on the variables window, you must add a expression to see them. F5 and F6 steps through your code and will be your best friend from here on :)
IMPORTANT NOTICE: While debugging stop all downloads, p2p programs and the like. As the debugging process is done by TCP protocol, these things will slow down the process. You have been warned.[/quote]
I start the VBA external tool process. I then start the GDB debugger and get the following error:
[quote]Failed to set program arguments, environment or working directory.
Unable to set working directory: mi_cmd_env_cd: Usage DIRECTORY
[/quote]
Anyone have any suggestions?
So close!
Luke
#110156 - elmro - Sun Nov 26, 2006 2:25 am
I resolved my error - my eclipse workspace name had a space in it (documents and settings) and it didn't like that. I moved my workspace to "c:\workspace".
Now I am getting a new error when trying to debug the tutorial code.
VisualBoyAdvance-SDL version 1.7.1
Windows version
Seaching for file VisualBoyAdvance.cfg
Searching current dir: C:\VBA_SDL_1.7.1
Seaching home directory: C:\emacs\
Searching user profile directory: C:\Documents and Settings\Luke
Searching executable directory
Configuration file NOT FOUND (using defaults)
Parsing debug info
Seaching for file vba-over.ini
Searching current dir: C:\VBA_SDL_1.7.1
Seaching home directory: C:\emacs\
Searching user profile directory: C:\Documents and Settings\Luke
Searching executable directory
vba-over.ini NOT FOUND (using emulator settings)
Listening for a connection at port 55555
Got a connection from 127.0.0.1 1321
Color depth: 32
Unknown packet pf#d6
Shutting down
Closing remote socket
Closing listen socket
Any Ideas?
Thanks,
Luke
#110197 - gmiller - Sun Nov 26, 2006 5:32 pm
The startup of VBA shows that it is waiting for a connection and then go a connect so your emulator is getting connected to from the debugger. The bad packet message is the emulator complaining about the data the debugger sent.
The first part of the debugger packet dialog loads the elf file over the socket and then the debugger reads the debug information (which is embedded in the elf file with the "-g" switch on the compile and link) to set the debugger up to monitor your code. Just remember this is a two part debug process. One part is the VBA SDL code listening ready to accept commands over the socket. The other is the debugger (insight/gdb or a debugger that can send/receive gdb codes packets) which talks to VBA using gdb formatted socket messages.
The debugging (gdb) interface in VBA was not implemented very well so you will find some issues here. I got so frustrated with it that I finally fixed the implementation of the debugger and some other issues in VBA. I have not found a home for the code yet so there is no public place to put it. There are still problems with the interrupt implementation (ignoring REG_IE bit settings for some interrupts and key press interrupts happening multiple times) which I am going to look at when I get time. I could post the source and executable somewhere for public use if anyone can suggest a location. I took the 1.8.? implementation and fixed all of the debug problems I could find and it works well (I have been testing it for 3 to 4 months about 25 different people each month).
#110205 - Ant6n - Sun Nov 26, 2006 7:47 pm
how about sending it back to the vba people, seems like they'd like that
"There are several unofficial versions of VBA around, those people could contribute something back to VBA in form of patches, etc... "
http://vba.ngemu.com/
#110206 - gmiller - Sun Nov 26, 2006 7:51 pm
| Ant6n wrote: |
how about sending it back to the vba people, seems like they'd like that
"There are several unofficial versions of VBA around, those people could contribute something back to VBA in form of patches, etc... "
http://vba.ngemu.com/ |
I tried that and got no reply ... I am not sure anyone is working on the version I started with 1.8.0 Beta 3.