#33439 - BlackAura - Mon Jan 03, 2005 1:22 pm
I've been playing around with GBA development (I recently got a linker and a flash cart, and playing with real hardware is much more interesting than using an emulator), but I've been having some really weird problems.
First off, interrupts don't seem to work at all if I'm sending a multiboot image to a real GBA. They work fine in emulators and when burned onto a flash cart, but not when booted over the linker. I'm using Jeff Frohwein's crt0 and linkscript (v1.3), configured with interrupts enabled, using single interrupts.
Aside from that, I think the flash linker is screwing around with the GBA hardware. Virtually none of my code was working at all until I started calling SWI 01 (reset memory and registers) at startup, to clear everything except IWRAM and EWRAM. Even after that, the graphics don't look right. Some random colour (and not the transparent one) appears as transparent, but with a load of garbage behind it instead of the background colour. It also still does some rather insane stuff - putting in some code to wait for a vblank interrupt to occur (using the interrupt to set a flag) causes the palette to go nearly black, and the graphics to become corrupted. None of those problems show up when I'm using an emulator, or a copy burned to the flash cart.
Oh, if this helps... I'm using DevKitARM on Linux for the toolchain, Jeff Frohwein's crt0 and link script, a Flash2Advance linker with a Flash2Advance Ultra flash cart, if2a for multiboot loading, and ucon64 for flashing.
#33440 - MumblyJoe - Mon Jan 03, 2005 1:50 pm
Sounds like alot of bizzarre and seperate problems, could I have some more details (what linker version and software) and maybe some of your code (cut your secrets out first!) and I'll see what I can do.
_________________
www.hungrydeveloper.com
Version 2.0 now up - guaranteed at least 100% more pleasing!
#33447 - BlackAura - Mon Jan 03, 2005 3:42 pm
The code itself is pretty basic stuff. Or at least, I think it's pretty basic stuff. Source code, and binary (which is / should be multiboot-able):
http://files.frashii.com/~sp00nz/Doom/files/BlackAura/gba/code.zip
http://files.frashii.com/~sp00nz/Doom/files/BlackAura/gba/test.gba
It simply sets up the graphics hardware in mode 0, enables one background layer, copies some palette and pattern data into the appropriate place, sets up a simple name table, and then uses interrupts to scroll the screen.
Running it in an emulator (I've tried NO$GBA and VisualBoyAdvance), it works as expected. As does running it off a flash cart. Oddly, the program I've been using to re-flash the cart has stopped working, and I'm not completely sure why...
At the moment, the code appears to be running from multiboot, but it's not working correctly. The pattern data is being loaded correctly, but the palette isn't, and the interrupts don't appear to be working. Previously, it was doing all that crazy stuff I mentioned before. Since then, I've yanked the linker cable out and plugged it back in, and it seems to be doing something slightly different now.
As for software / hardware, I'm using if2a 0.9.2 (on Linux) to load multiboot images, and ucon64 to flash the cart. I have a Flash2Advance USB linker (I don't know what version), using the firmware that comes with if2a, the GBA loader program that comes with if2a (v2.4b), and it reports the flash card as being an F2A-256M ultra-B.
I haven't tried the Windows software, because I haven't been able to get it to work. Last time I tried, the drivers simply refused to find the linker cable, so it kept coming up as "Unknown Device", or something like that...
I think there may be something wrong with the software / the hardware / my code / all three, but I have no idea how to track it down. Oh, and I tried a few other multiboot-able game images... None of them work either. Most of them either do nothing, or lock up immediately.
#33449 - dagamer34 - Mon Jan 03, 2005 4:46 pm
As far as I know, the GBA doesn't really clear the RAM like it should when you first start a program. But there must be some garbage in there in the first place though.
It's probably the flasher itself it you have tried other multiboot images. I would try to find another flashing program (I think F2A cables can use more than one, PowerWriter comes to mind) and see if it works then.
_________________
Little kids and Playstation 2's don't mix. :(
#33451 - ScottLininger - Mon Jan 03, 2005 5:36 pm
The only thing I've run into that can cause really weird behavior on hardware is failing to declare your registers as volatile...
But you're doing that, so it must be the interrupt code. Have you tried removing that part from the code entirely, and just executing the bits that make the background appear?
-Scott
#33488 - BlackAura - Tue Jan 04, 2005 11:23 am
Just tried it using PowerWriter... Same thing happens. I think the loader program is leaving the GBA in some kind of weird state that seems to break things.
I tried to get if2a to load a multiboot image directly, but I've been unable to do that so far. It should be able to do it (because the loader is, after all, a multiboot program) but no matter what I do I still get (part of) the loader. It seems that the F2A linker itself is sending the first part of the loader to the GBA, so I might have to hack at the firmware...
I yanked the interrupt code out of there entirely. It works, but still not correctly. I still get the same palette or image corruption, there's still garbage all over the screen, certain colours still display incorrectly, and it still works perfectly if I write it to the flash cart.
I'll see if I can grab a digital camera, and take some pictures of it.
#33508 - ScottLininger - Tue Jan 04, 2005 6:53 pm
So does it work correctly if you *don't* make the program a multiboot? You imply that this is the case, but I just wanted to make sure.
Another question: have you tried downloading somebody else's multiboot program and running that through your flash linker? There are lots of these on the main site. Or my ThingPong game is multiboot. You could test with that.
Photos would definitely be interesting to see. Sounds like a really weird problem. :)
-Scott
#33559 - BlackAura - Wed Jan 05, 2005 12:26 pm
Yes, it works correctly if I don't make it a multiboot program. Not if I try to boot it as a multiboot program, obviously, but from a flash cart.
I tried ThingPong, and it works perfectly. There's some garbage on-screen at the beginning, which is probably something left in VRAM by the loader program, but other than that...
I grabbed the source code and had a look at it... The only difference appears to be that ThingPong doesn't use interrupts, but my code does.
So, I disabled the interrupt code entirely in crt0, and it works. If I enable interrupt support again, it breaks, even if I don't actually enable interrupts.
I grabbed some other multiboot programs, and sure enough, programs that use interrupts just do not work (they usually lock up, display corrupted graphics, or do absolutely nothing at all), while programs that do not use interrupts work fine.
So here's the real question... What the hell is happening? It seems that the interrupt handling code in crt0 is screwing things up somewhere when using multiboot, but if that code was faulty someone would have noticed it by now. Maybe the loader program is screwing things up? But I really don't see how that could be, because the loader program is gone by the time that code is executed...
#33569 - tepples - Wed Jan 05, 2005 4:37 pm
Have you tried a program such as TOD? It is a multiboot, and it uses the vblank interrupt for power-saving.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#33581 - ScottLininger - Wed Jan 05, 2005 8:11 pm
| BlackAura wrote: |
| There's some garbage on-screen at the beginning, which is probably something left in VRAM by the loader program, but other than that... |
Oh... what Flash Cart are you using? Maybe it's the "loader program" that's hosing up your results. Have you tried it without the loader, and just burned your ROM as the main executable?
There should be an option to turn off the loader program... Who knows what changes it might be making to your header or how the backswitching works? Might just be the answer.
-Scott
#33590 - dagamer34 - Wed Jan 05, 2005 9:24 pm
What KIND of interrupt setup do you have? Single, Multiple, Fast?
_________________
Little kids and Playstation 2's don't mix. :(
#33629 - BlackAura - Thu Jan 06, 2005 5:13 am
| Quote: |
| Have you tried a program such as TOD? It is a multiboot, and it uses the vblank interrupt for power-saving. |
Yep. Doesn't work. It locks up on the logo screen, although the logo itself appears to display correctly.
| Quote: |
| Oh... what Flash Cart are you using? Maybe it's the "loader program" that's hosing up your results. Have you tried it without the loader, and just burned your ROM as the main executable? |
A Flash2Advance Ultra 256M. I've tried burning to the cart both with and without a loader, and it works. The loader resets the system after you choose something to run anyway, so it seems to clean up after itself pretty well.
However, when I'm trying to multiboot something, the software (both the official stuff and if2a) first loads the GBA-side client program that is used to flash the cart. It then uses that program to transfer the multiboot image, and starts it from there (presumably by jumping to 0x02000000 - it doesn't reset as the flash cart loader does).
That loader program leaves garbage in VRAM, and seems to be screwing stuff up. I haven't managed to get any of the software I have to load a multiboot image without first loading the GBA client program.
I also get the same results if I pull the flash cart out. So it's not a problem with the flash cart, as far as I can tell.
| Quote: |
| What KIND of interrupt setup do you have? Single, Multiple, Fast? |
Single.