Discussion about software development for the old-school Gameboys, ranging from the "Gray brick" to Gameboy Color
(Launched in 2008)
You are not logged in.
**NOTE: It was fixed by me updating to GBDK 2020. Thanks to everyone who helped!
I'm making a GBC game with GBDK, and everything's been running smoothly so far. However, I've just encountered a problem - I usually test my game on both an emulator on my computer (VisualBoyAdvance) and an emulator on my Raspberry Pi (lr-gambatte), but with a new update I added to my game, it only works with VBA.
Granted, the sprites and backgrounds load up with gambatte, but it's impossible to move and the sprites look almost completely corrupted. It looks almost like an issue with variables or addresses overflowing, but with it running well on VisualBoyAdvance, I honestly don't know. Also GBDK is still letting me export, when it wouldn't let me export if there was an address overflow.
It's also most likely not a problem with lr-gambatte itself, since it runs other games just fine with no issues. What could be the problem?
Here's the game, if anyone else wants to try it and see if it works.
https://drive.google.com/file/d/1RrRD-j … sp=sharing
UPDATE:
The game still doesn't work on the emulator, however I figured out the difference between the two emulators - One is a GBA emulator and one is a GBC emulator. For whatever reason, the game runs perfectly fine on GBA but doesn't on GBC. I tested multiple emulators, both GBA and GBC and they both showed the same thing. However, my question still stands, why does it do this? What is the issue?
Last edited by Bobyrman123 (2022-02-09 20:00:21)
Offline
You should really never use VBA. It's old an very inaccurate and doesn't at all represent how the game will run on hardware. BGB is a good choice and has a debugger. Other good choices are Sameboy and Emulicious.
The issue in this case seems to be caused by the instruction at $359B:
add SP, $6F
This adds an offset to the stack pointer, which makes the stack underflow and SP ends up in what is called echo RAM. Echo RAM is like a second copy of the same memory that's mapped to $C000-$DFFF. So when the a subroutine is called later on, it pushes the return address to somewhere in the $E0xx range, which overwrites data in $C0xx. This probably trashes game variables.
The code looks like compiled C code, so I don't know if this is assembly code you wrote by hand or compiler output. In the latter case, this may be a bug in the compiler. The first course of action would be to upgrade to GBDK-2020 if you're using an old version of GBDK. Also, avoid allocating large local variables in functions. (Like large arrays and similar.) Allocate them as global variables instead. This may seem like bad practice, but may be necessary to solve your problem.
Offline
It loads on my original Gameboy (with a chinese flash card) and also on Ares and Sameboy but the sprites look kind of corrupted and you can only 'move' by 1 pixelblock (8x8) to the right and left.
So I think it behaves on original and the other emulators similar to yours on Gambatte.
Are you using GBDK2020 ? (https://github.com/gbdk-2020/gbdk-2020)
Last edited by M2m (2022-02-08 22:57:29)
Offline
I just now realized that I'm following a tutorial that has me use the original GBDK rather than GBDK 2020... And yes, I am using compiled C rather than assembly, so it must be an issue with the old GBDK.
I'm gonna update my GBDK and try and change my variables' scopes and see if either of those work.
I'll keep you guys updated! Thanks for your help!
Offline
Yep, everything's working just fine! Thank you guys for your help, I honestly had no clue I was running an older version of GBDK. You guys are the best!
Offline