- General FAQ
-
- Installation Problems
-
- Q: How do I install the Linux version?
- A: Just unpack it to any directory of your choice and run the "runme" shell script. You will then be walked through the installation process using a simple multiple choice configuration utility. Notice HAM might need to download about 50 MB of source code from a GNU site near you.
- Q: How can I upgrade my compiler / debugger / etc (Windows or Linux)
- A: In Linux, just rerun the "runme" script, and follow the instructions. On Windows, you will need a working Cygwin setup on your system, and unpack the linux compiler builder distribution into a directory of your choice reachable from the Cygwin system. Then run the "runme" and follow the instructions. You might need to make sure that during the Cygwin installation, a few additional utilities such as "wget" and "perl" need to be installed.
- Compilation Problems
-
- Q: HAM is VERY slow. My program takes ages to compile!
- A: This might be due to a known Cygwin bug. Cygwin has a slight bug that makes it delay for quite a while if a mounted volume is unreadable. To avoid this delay, you have to put media in each drive, disconnect drives you aren't using, or change the Cygwin config files. (I don't know deep cygwin wizardry so I can't help you there.)
- Q: Since v2.30, nothing compiles! I get "Badly punctuated parameter list" errors!
- A: This is related to a problem with a Cygwin setup on your system. Either reinstall Cygwin with the DOS style path setups, or, if you already deinstalled Cygwin, search your registry and delete all Cygwin keys and delete them. It also helps to just get the Setup.exe from http://sources.redhat.com/cygwin, and in the installer, select DOS as text file handling mode. You do not need to change anything else, so nothing will be overwritten when you finish the installer.
- Q: Since v2.40, I get "undefined reference to main()" errors!
- A: Your old projects need a little change that I had to put in for enabling C++ support in HAM. Just change your AgbMain function name to main and you should be good to go.
- Q: My program worked, but now I added something and it does not anymore!
- A: Make sure you have NOT set the MULTIBOOT define at the top of your source code. Multiboot programs can only be 256kb, usually even a bit less.
- Q: I seem not to be able to compile anything. All the compiler says is "Error 1" when attempting to compile.
- A: The problem is likely an incompatible version of cygwin1.dll on your system. Do a system wide search for the file "cygwin1.dll" and rename all of them as you please into some other name (all except the one in the HAM installation folder of course). Note this could impact the functionality of other programs, so do not delete any files!
- Q: Krawall specific: if I run "make" i get an error that samples.o cannot be made.
- A: The first time you compile, this can happen. Run a "make clean" and it will work afterwards.
- C++ Problems
-
- Q: How do I compile C++ files?
- A: Just name them filename.cpp instead of filename.c ... You should even be able to mix C and C++ in the same project.
- Q: In 2.40 C++ Support should work right? I cannot use XYZ from the C++stdlib!
- A: Yep, C++ is supported, and there is a crude C++lib also, but most of it is useless on the GBA. Using the C++ library functions such as streams should be avoided... the GBA is a tiny platform remember...
- Sound Problems
-
- Q: The sound from the afm modplayer stutters / crackles / etc
- A: Make sure you call afm_Sync at the start of your VBL interrupt handler. If this does not help, your program is too busy. I have not written the mod player, so I will not improve it. Also consider using HAMs Direct Sound support, or even better, use Krawall. See the krawall sample source code for information on how to get it running for your program.
- Q: In my program (including modplayer sound) I changed some stuff that REALLY should not break anything, but now it crashes!!
- A: This has been reported a number of times, and is due to afm. Disable the modplayer and retry. If you can, I urge anyone to switch to Krawall, which is much more stable.
- Q: How do I compile WAV files to go into my GBA ROM ?
- A: Very easy. Just add them to the .o files in your makefile, and make sure you have them in the same directory as the makefile. Example, to add cool.wav, just add "cool.o " to the object list in your makefile, an d, in addition, declare an extern global in your source code, that would look like "extern const WaveData _binary_cool_raw_start;" . Thats all, you can now use this WaveData structure to access the sound data and feed HAMlib with it.
- BG functionality problems
-
- Q: I convert the graphics and load them onto my BG, but they appear "sliced" (e.g. only every second tile is displayed)
- A: You are displaying a map on a rotating/scaling BG that has not been converted as a rotation map. You have to convert your graphics in gfx2gba using the "-rs" switch.
- Q: I want all black pixels in my BG to be transparent, but it does not work. Why?
- A: You will need to set the color number 0 (in your paint applications palette) to the one you want to be transparent. This is true for Sprites and BG in tiled mode.
- Q: I modified the picture in a sample source code, but I don't see the changes on the GBA / the graphics are messed up?
- A: You will need to learn how to use gfx2gba. The documentation for this tool is here
- Bitmap mode problems
-
- Q: I set my BGMode to number 4 or 5, and used ham_PutLine() or ham_PutPixel() , but nothing shows up. Whats wrong? It works fine in Mode 3.
- A: Mode 4 and 5 have a so called double buffer. HAM will always plot to the buffer that is currently not displayed. You can flip the back buffer to the front by calling the ham_FlipBGBuffer() .
- Sprite problems
-
- Q: After allocating/deallocating sprites a few times, my code crashes. Whats wrong?
- A: This might be related to a memory leak in the OBJ system in HAM 2.4 . It should be gone in HAM 2.5
- Q: I am using ham_CreateObj and/or ham_DeleteObj every frame, and my program crashes at random locations. Why?
- A: The Problem is most likely that your VBL interrupt routine disrupts one of the calls to the functions above, and before they get done, there is yet another scheduled interrupt. Because of this, you may run into a stack overflow/crash. To get around this problem, use M_INTMST_DISABLE before your CreateObj call, and M_INTMST_ENABLE after it. This will protect the routine from being interrupted.
- Memory Allocation problems
-
- Q: I need a variable in a specific memory area, like IWRAM. How can I do this?
- A: just make it a global, like this: u16 foo MEM_IN_IWRAM; You can also force EWRAM.
- Debugger problems
-
- Q: How can I use the GDB Debugger, how do I use it?
- A: Using the debugger is easy as toast! Just compile using "make gdb". For instructions on how to use the debugger, see http://sources.redhat.com/insight/ . You will be presented the debugger and your VBA is ready to go. Press the "Continue" button or the "c" key on the keyboard to start the program. To return into the debugger, highlight the VBA window and press F11. To set breakpoints, click the little "-" signs next to the source.
- Q: I would like to profile my code, how can I do this?
- A: HAM provides a simple code profiler, that is very easy to use in conjunction with VBA. Just put TOOL_USE_PROFILER somewhere at the top of the source file you want to debug, and then put TOOL_PROFILER_START and TOOL_PROFILER_END around the code block you want to measure. You will then get a report about the time elapsed in the console of VBA. For more information, look up the information on TOOL_USE_PROFILER in include/mygba.h .
- Q: It seems like when I debug step by step in my source code, the order of the functions called is not correct. Whats wrong here?
- A: This might be related to the compiler optimizing your code too much. You can change the optimization level down to -O1 , which should work well for the Debugger. The switch to change can be found in the HAM_CFLAGS variable in system/master.mak
- VBA Emulator problems
-
- Q: I cannot quit the emulator when running "make vba"
- A: Press ESC to quit the emulator
- Q: My program works fine on the emulator, but performance is worse on real hardware. What could be the cause?
- A: As of October 2002, VBA is known to handle emulation of DMA calls too fast. Real DMA is a bit slower on hardware, so you need to be careful when only testing DMA heavy code on the emulator.
Documentation Homepage |
HAMLib reference |
Back to HAM Homepage
