#65152 - Voelker - Fri Dec 30, 2005 6:18 pm
I have recently bought a EZFA usb cable to load my programm into my gba with no need of an expensive cartridge. But when i load one of my programm sprites doesn't work but background display and i can use the keypad. This problem also occur with progs downloaded on the internet. The only programm i found working well with this cable is thingpong which use sprites. I d'ont know what to do to get my own programm working, so please help me ...
#65164 - Dwedit - Fri Dec 30, 2005 8:59 pm
Sounds like the linker software boots the game into a dirty state. Try manually resetting every register to what they should be before initally booting up.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#65171 - tepples - Fri Dec 30, 2005 9:57 pm
RegisterRamReset(0xFC) should do most of what you want.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#65187 - wintermute - Sat Dec 31, 2005 4:01 am
| tepples wrote: |
| RegisterRamReset(0xFC) should do most of what you want. |
Unlikely, the problem is with the multiboot loader in EZFA and, afaict, every USB based link port cable I've been able to lay my hands on.
Xboo Communicator will run code fine since the uploaded application is booted directly. See http://www.devkitpro.org/downloads.shtml
I'm currently looking into supporting some USB cables with this app, I have an XG2 cable but donations of other cables would be appreciated :P
#65188 - Dwedit - Sat Dec 31, 2005 4:19 am
I've verified that the data sitting in EWRAM is identical to the original file when multibooting with a F2A cable. But why would it fail to run in a dirty environment?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#65189 - wintermute - Sat Dec 31, 2005 4:36 am
| Dwedit wrote: |
| I've verified that the data sitting in EWRAM is identical to the original file when multibooting with a F2A cable. But why would it fail to run in a dirty environment? |
It's not a dirty environment as such. The loader tries to run apps in user mode so it can't set up it's IRQ stack.
#65190 - Dwedit - Sat Dec 31, 2005 5:13 am
Any good way to get out of user mode? Does the bug that lets you dump the bios also allow you to get out of user mode?
edit: nope, it was a dumb suggestion anyway...
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#65194 - chishm - Sat Dec 31, 2005 7:12 am
| wintermute wrote: |
| It's not a dirty environment as such. The loader tries to run apps in user mode so it can't set up it's IRQ stack. |
I had this problem with the GBAMP FW hack. To fix it, you need to be able to modify the multiboot loader. Run it through a disassmbler, or even VBA. Find the last mode change instruction (tends to be a mov r0, #x; msr cpsr, r0; where x is the mode value) and change it to a switch to supervisor mode, by changing the mov r0, #0x50 to mov r0, #0x5f. This should fix that particular problem.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#65197 - wintermute - Sat Dec 31, 2005 7:54 am
| chishm wrote: |
| wintermute wrote: | | It's not a dirty environment as such. The loader tries to run apps in user mode so it can't set up it's IRQ stack. |
I had this problem with the GBAMP FW hack. To fix it, you need to be able to modify the multiboot loader. Run it through a disassmbler, or even VBA. Find the last mode change instruction (tends to be a mov r0, #x; msr cpsr, r0; where x is the mode value) and change it to a switch to supervisor mode, by changing the mov r0, #0x50 to mov r0, #0x5f. This should fix that particular problem. |
Unfortunately in some of the devices I've looked at so far the loader is embedded in the driver :/
#65198 - Dwedit - Sat Dec 31, 2005 8:15 am
As long as it's not compressed or encoded in any strange way, if you can find the multiboot program, you can modify it with a hex editor. Just gotta find it. Usually lots of 4 byte words with the MSB beginning with E indicates ARM code, look for a bunch of E3's, E5's or E1's making columns. Maybe some 1A's in there too.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#65204 - Voelker - Sat Dec 31, 2005 2:42 pm
How do you explain that the game thing pong which is using sprites and is setting is own IRQ, is running with this cable ?
#65205 - wintermute - Sat Dec 31, 2005 3:00 pm
| Voelker wrote: |
| How do you explain that the game thing pong which is using sprites and is setting is own IRQ, is running with this cable ? |
Probably because it happens to use the same crt0 as the loader in the cable & the stacks happen to be in the same place so nothing breaks.
#65211 - wintermute - Sat Dec 31, 2005 7:13 pm
| Dwedit wrote: |
Any good way to get out of user mode? Does the bug that lets you dump the bios also allow you to get out of user mode?
edit: nope, it was a dumb suggestion anyway... |
That bug doesn't but there's an undocumented SWI (0xd4) which jumps to 0x02002040 which could be used to jump back to the crt0 in supervisor mode. I'll have a look at adding some suitable code to the default crt0.
If you want to test something in the meantime, the crt0 source and makefile is provided in the arm-elf/lib directory of devkitARM. Just open an msys shell, set the PATH if needed & execute make CRT=gba
| Code: |
davem@NEUROMANCER /e/devkitPro_test/devkitARM/arm-elf/lib
$ PATH=$PATH:$DEVKITARM/bin make CRT=gba
arm-elf-gcc -x assembler-with-cpp -marm -c gba_crt0.s -ogba_crt0.o
arm-elf-gcc -x assembler-with-cpp -marm -mthumb-interwork -c gba_crt0.s -o interwork/gba_crt0.o
arm-elf-gcc -x assembler-with-cpp -mthumb -c gba_crt0.s -o thumb/gba_crt0.o
arm-elf-gcc -x assembler-with-cpp -mthumb -mthumb-interwork -c gba_crt0.s -o thumb/interwork/gba_crt0.o
|
#65224 - tepples - Sun Jan 01, 2006 2:29 am
| wintermute wrote: |
| there's an undocumented SWI (0xd4) which jumps to 0x02002040 which could be used to jump back to the crt0 in supervisor mode. I'll have a look at adding some suitable code to the default crt0. |
Wouldn't that seem to require reserving the first 8 KB of the program? And has the Game Boy micro's BIOS changed in any way that would keep this from working? And what effect would it have on emulators that high-level-emulate the BIOS (in order not to require the user to dump a BIOS file) and don't know what to do with SWI 0xD4?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#65292 - wintermute - Sun Jan 01, 2006 10:37 pm
| tepples wrote: |
| wintermute wrote: | | there's an undocumented SWI (0xd4) which jumps to 0x02002040 which could be used to jump back to the crt0 in supervisor mode. I'll have a look at adding some suitable code to the default crt0. |
Wouldn't that seem to require reserving the first 8 KB of the program? And has the Game Boy micro's BIOS changed in any way that would keep this from working? And what effect would it have on emulators that high-level-emulate the BIOS (in order not to require the user to dump a BIOS file) and don't know what to do with SWI 0xD4? |
GB Micro BIOS is identical.
Code to use this method would obviously save and restore the contents of the memory when using the SWI so there would be no need to reserve memory.
I suppose code could be used to detect emulation and execute the code as appropriate.
#65316 - Dwedit - Mon Jan 02, 2006 12:41 am
What registers are destroyed by the SWI to enter supervisor mode?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."