#16517 - subatomic - Wed Feb 18, 2004 4:45 pm
I have a C++ app compiled with gcc 3.3.2 (built from the toolchain Makefile at http://www.geocities.com/xgoatboyx/index.html)
This game works in VisualBoyAdvance but when I load it onto my flash cartridge, the actual GBA hardware only shows a white screen. Also, none of the names or RAM sizes are set on the .gba like with other gba rom "backups"...
- Is there a checklist of things to look for, or things I need to do to my rom file to prepare it for real hardware? Could it be some flag in crt0.s or lnkscript?
- Also, how would I debug something like this?
- Possibly related... how do I set up the cart parameters (RAM size, name, etc...) that I see onther carts have?
- Anyone have a demo that definately runs on the GBA I could look at?
- I'm programming in C++, is there anything special about c++ that would make a difference?
thanks!!!
#16518 - subatomic - Wed Feb 18, 2004 4:47 pm
note... i'm using the EZF advance Realtime 256M flashcart... and version 1.0 of their client.
I tried it with both multiROM enabled and without...
#16519 - poslundc - Wed Feb 18, 2004 5:19 pm
I think you're going to have to post some code if you want us to be able to help with debugging it.
How simple a program is it? Try stripping away as many of the "extras" as you can (especially if you have things like interrupts running) and just try to get a simple program that works. That makes it much easier to isolate the piece of code that's causing problems for you.
All of the demos from my website should work with an EZ-Flash, and they are just compiled/linked with gcc; no fancy extras.
Dan.
#16523 - qw3rty - Wed Feb 18, 2004 7:09 pm
You could try fixing the .gba wit "gbafix.exe" and pad it to the next "legal" size...
I once had a similar problem, and fixing the bin did the trick...
(although in most cases this isn't necessary...)
#16525 - Blacken - Wed Feb 18, 2004 10:15 pm
Emulators are frequently more forgiving code-wise than the GBA hardware itself. Don't try to be too fancy for what you're doing. ;)
#16529 - subatomic - Thu Feb 19, 2004 12:04 am
thanks for the tips... maybe gbafix will work, i'll try when I get home tonight....
it looks like gbafix does some things I didn't know I had to do in my source...
- is there a doc I can read on how to set up my source to compile with the appropriate header info? all I do is compile with crt0.s (v1.28 from JF) as the first .o file. then link with same version lnkscript... then use objcopy.
I'm assuming maybe I should have special data in the code to set up the header info? or maybe we're all supposed to use gbafix.exe? I also dont pad my rom file... it's about 200k total...
anyway, send me reading material, i'd like to RTFM - i just haven't seen anything on gbadev.org or on http://www.devrs.com/gba/....
#16530 - subatomic - Thu Feb 19, 2004 12:10 am
| Blacken wrote: |
| Emulators are frequently more forgiving code-wise than the GBA hardware itself. Don't try to be too fancy for what you're doing. ;) |
I figured as much. :) well, I'm using c++, which seems more fancy than anyone's examples... though it's pretty simple so far. I also tried slideshow from http://www.geocities.com/xgoatboyx/index.html, didn't work either, and it seems to be really simple.
#16531 - subatomic - Thu Feb 19, 2004 12:23 am
| poslundc wrote: |
I think you're going to have to post some code if you want us to be able to help with debugging it.
|
I may do that later, but for now I just wanted to make sure I understood all the setup requirements for creating a proper rom file for use on the hardware.
| poslundc wrote: |
How simple a program is it?
|
not very, though if gbafix doesn't work I'll be stripping it down. :)
| poslundc wrote: |
Try stripping away as many of the "extras" as you can (especially if you have things like interrupts running) and just try to get a simple program that works. That makes it much easier to isolate the piece of code that's causing problems for you.
|
I planned to. was just looking for a troubleshooting guide/FAQ, and/or document explaining how to setup the rom's header (other than GBAFIX)...
| poslundc wrote: |
All of the demos from my website should work with an EZ-Flash, and they are just compiled/linked with gcc; no fancy extras.
Dan. |
awsome. I'll compare mine to yours. thanks for the link.
#16532 - tepples - Thu Feb 19, 2004 12:25 am
Padding a ROM file shouldn't affect whether it works on a flash cart. Flash writer programs will do any padding needed for the particular cart.
All Gbafix does is add a valid header including the 156 Byte Magic Cookie. If you see "GAME BOY" across the top of the screen and "Nintendo" across the bottom, you have a valid header. Many flash writer programs will correct the header for you.
If you get a white screen after the "GAME BOY" logo, then you have a bug in your code.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#16538 - subatomic - Thu Feb 19, 2004 2:51 am
| tepples wrote: |
Padding a ROM file shouldn't affect whether it works on a flash cart. Flash writer programs will do any padding needed for the particular cart.
All Gbafix does is add a valid header including the 156 Byte Magic Cookie. If you see "GAME BOY" across the top of the screen and "Nintendo" across the bottom, you have a valid header. Many flash writer programs will correct the header for you.
If you get a white screen after the "GAME BOY" logo, then you have a bug in your code. |
I get "GAME BOY", but the nintendo is garbled... it's a block of noise instead of the word "nintendo"... then I do get a white screen after that goes away... i'll check the code.
Is the "valid header" written using the arm-thumb gcc crt0/lnkscript? or should I have done something in code? (i'm not)...
#16539 - poslundc - Thu Feb 19, 2004 3:06 am
| subatomic wrote: |
| I get "GAME BOY", but the nintendo is garbled... it's a block of noise instead of the word "nintendo"... then I do get a white screen after that goes away... |
Oh crikey, the physical connection is probably just dirty. I get that happening all the time. Try blowing into the cartridge, the GBA and the linker to clear any dust out. Reformat your cartridge and try again.
If you're still running into problems, dip a q-tip into rubbing alcohol and gently clean the contacts off on all three units.
Dan.
#16540 - tepples - Thu Feb 19, 2004 3:16 am
If the "Nintendo" is garbled, it's most likely a header problem. (If the cart was dirty, you probably wouldn't even get a garbled mess because the checksum on the rest of the header wouldn't check out.)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#16541 - dagamer34 - Thu Feb 19, 2004 3:31 am
Since you are using the EZFA client, I have specific help for you.
If you put on a ROM with MultiROM enabled, the GBA doesn't know that your ROM has a bad header, it doesn't even check it. However, if you don't have MultiROM enabled, then it is as if its a real ROM, it does header checking on the ROM itself.
But the EZFA client software should automatically patch the ROM for a correct header anyway.
_________________
Little kids and Playstation 2's don't mix. :(
#16542 - poslundc - Thu Feb 19, 2004 4:16 am
| tepples wrote: |
| If the "Nintendo" is garbled, it's most likely a header problem. (If the cart was dirty, you probably wouldn't even get a garbled mess because the checksum on the rest of the header wouldn't check out.) |
I get this happening all the time as a result of cartridge dirt... the "Gameboy" appears just fine but the "Nintendo" is a garbled mess.
Dan.
#16543 - DekuTree64 - Thu Feb 19, 2004 4:32 am
I tried flashing a ROM with MultiROM turned off yesterday and got a garbled Nintendo. Then I tried it with MultiROM and it worked fine. I think it is the header, and the EZF client does bypass the checking when you start a ROM from the loader menu. So try it with MultiROM, or try a header editing utility.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#16551 - FluBBa - Thu Feb 19, 2004 1:49 pm
If you want your GBA emulator to behave more like a real GBA hunt down a (or dump your own) BIOS and use with the emu.
_________________
I probably suck, my not is a programmer.
#16554 - poslundc - Thu Feb 19, 2004 3:50 pm
| FluBBa wrote: |
| If you want your GBA emulator to behave more like a real GBA hunt down a (or dump your own) BIOS and use with the emu. |
That only would make any difference for the BIOS system calls, which aren't typically a source of errors between emulation and hardware. Much more likely to be a source of problems is the inaccurate timing of waitstates in emulation and any incorrect handling of ISRs in the code (which I've found emulation to be more forgiving about).
Dan.
#16603 - FluBBa - Fri Feb 20, 2004 2:29 pm
Yes it's mostly for SWI's and such but also as in this case the checking of the GBA header.
_________________
I probably suck, my not is a programmer.
#19756 - notb4dinner - Sun Apr 25, 2004 1:57 am
Although in your case it sounds like a header problem, something else I've just come across something alse that can cause a program to behave differently on hardware and an emulator is reading uninitialised RAM. Visualboy Advance seems to initialise all it's RAM to 0 (ie. NULL) while the hardware's is in an undefined state to begin with.
#19757 - poslundc - Sun Apr 25, 2004 2:09 am
The crt0.o that is compiled/linked with your program zeros all memory on initialization, ie. before your program launches.
I have also heard that the GBA automatically zeros all memory when it is turned on, although I have not confirmed this.
Dan.
#19766 - torne - Sun Apr 25, 2004 10:38 am
I'm fairly sure that on poweron, the GBA does the equivalent of SWI 1 with r0 set to 255 before it boots, which will clear all IO registers, memory..etc. I've not checked this, though..
#19820 - notb4dinner - Mon Apr 26, 2004 2:58 am
Interesting... that's not the behaviour I was observing but I could very well have been confused.
#19837 - FluBBa - Mon Apr 26, 2004 3:08 pm
VBAs emulation of the SWIs is not perfect, it fails to initialize some regs at least when using the reset functions.
A real GBA clears all memory and resets all HW registers before your program gets the control.
Edit: a possible explanation for the wierd behaviour in that the GBA not reseting everything might be your bootmenu (ROM menu, pogoshell...).
_________________
I probably suck, my not is a programmer.
Last edited by FluBBa on Tue Apr 27, 2004 11:02 am; edited 1 time in total
#19853 - dagamer34 - Mon Apr 26, 2004 10:30 pm
One example of VBA's almost perfect SWI emulation is calling the RegisterRamReset swi (0x01). Real hardware will turn off all backgrounds, set the mode to 0, and set the force blank bit, whereas VBAs internal bios does none of that.
_________________
Little kids and Playstation 2's don't mix. :(