Gambatte 0.5.0-wip2 released

[vigi_lante]

Congratulations. Top Notch work. I'm also only waiting the joypad support to start to play it more seriously.

Just one problem...

I'm using a television as a second screen to my PC, but even considering I'm using it as the primary display monitor, sometimes, when I switch to fullscreen, the emulator display the picture on the secondary display monitor, and not on the primary.

[franpa]

aside from some audio popping as text is typed onto the screen in Ocarina Of Ages, the games plays flawlessly so far.

i believe the freezing was in Links Awakening and that it was caused by "cheats", i've beaten it without cheats tho so... dont worry about that freezing issue i reported earlier.

[DancemasterGlenn]

Ocarina Of Ages

*cough* (oracle)

EDIT: But seriously, very nice emulator! I'm a sucker for joystick support, and I hope it'll be added in a future release. Keep it up!

That really shouldn't have been the afterthought-edit part...

[Panzer88]

does it emulate super gameboy borders and colors? I realize this isn't actually technically a gameboy function, but other emus have done it.

[sinamas]

I'm using a television as a second screen to my PC, but even considering I'm using it as the primary display monitor, sometimes, when I switch to fullscreen, the emulator display the picture on the secondary display monitor, and not on the primary.

I'm not sure how to deal with that. It may be a shortcoming in the Microsoft API I'm using for changing video mode.

aside from some audio popping as text is typed onto the screen in Ocarina Of Ages, the games plays flawlessly so far.

That game can sound a bit poppy on hardware too it seems. I found an old bug in the frequency calculation for the noise channel however, which is fixed in svn. Not sure how I managed to miss that until now.

The sound of my emulator in general tends to be more similar to a gba than a gbc. I think the gbc has some kind of low-pass filtering at the output stage. On the plus side this means the sound is a bit clearer, on the negative side there are some games using ch3 for sample playback that suffer some high-pitched noise. The low-pass algorithm will probably have to be approximated through testing.

does it emulate super gameboy borders and colors? I realize this isn't actually technically a gameboy function, but other emus have done it.

It doesn't and it probably never will (unless I decide to make a full SNES emulator, which is unlikely).

[franpa]

in Zelda Oracle Of Seasons there is a bug with the pirate ship setting sail. when it sets sail for the first time there will be a abnormal graphic glitch in the screen.

aside from that, i've almost finished the game.

[vigi_lante]

I'm not sure how to deal with that. It may be a shortcoming in the Microsoft API I'm using for changing video mode.

Maybe an option to select the display device, like Visual Boy Advance and Nestopia have.

[Panzer88]

that's what I thought, but does the Super gameboy even use any of the SNES hardware? I thought it had all the gameboy hardware was built into the cart. I suppose it can, but most games just added borders etc. It is just interesting because an SNES emu author won't make it because it's a gameboy devise but a Gameboy emu author won't make it because it is a SNES game devise. Sorry for my ignorance, I really do think what you are doing is great.

[creaothceann]

Some games use the infamous "toggle visibility every other frame" effect.
sinamas, have you thought about adding a feature like VBA's motion blur / interframe blending (pic) ?

that's what I thought, but does the Super gameboy even use any of the SNES hardware? I thought it had all the gameboy hardware was built into the cart. I suppose it can, but most games just added borders etc. It is just interesting because an SNES emu author won't make it because it's a gameboy devise but a Gameboy emu author won't make it because it is a SNES game devise. Sorry for my ignorance, I really do think what you are doing is great.

Maybe a fusion of bsnes and Gambatte...

Anyway... IIRC there are a couple of games that use SNES features, apart from the borders.

[OmegaX]

I found a bug in Pokemon Crystal (latest SVN revision as of today #53 I think), the game plays slow and the sound is terrible, the same ROM works fine on VisualBoyAdvance. I tried with Zelda DX and everything was fine with that game.
I used the SDL version BTW, I haven't tried QT because I don't want to install KDE libraries.
The emulator seems nice, I can't wait to try it when you add more features like Gamepad support and configuration files to store roms and saves paths.
Keep up the good work

EDIT: Retried Zelda DX and the sound got messed up there too, It only worked fine the first time I tried, I closed any other programs that might be interfering with the sound but the problem persists.

[byuu]

Maybe a fusion of bsnes and Gambatte...

How did I know someone would say that :P

It doesn't matter whether the SNES emu is added to the GB emu, or vice versa.

However, our licenses are incompatible, and on projects as big as emulators, that's not something either side should be asked to compromise on.

Plus you're really asking too much. Both systems take years of time and effort to emulate, and all that you'll gain over what's available now is one or two tiny features in Space Invaders or something (::waits for someone to inevitably chime in with a comprehensive list of every single thing true SGB emulation would add::). Point being, as with emulating Game Genie BIOSes, the time could be better spent elsewhere.

Also, we have no way of testing the actual GB<>SNES interface apart from disassembling the SGB BIOS, which is a terrible way to emulate something accurately. And even if we did have a test rig, I'm sure no emulator author would want their prized emulator to just be a small 'feature' in another emulator.

And that's not even including all of the time it would take to merge two very, very large projects together.

[creaothceann]

Maybe a fusion of bsnes and Gambatte...

How did I know someone would say that

I was just joking. But the question tends to pop up from time to time.

[sinamas]

in Zelda Oracle Of Seasons there is a bug with the pirate ship setting sail. when it sets sail for the first time there will be a abnormal graphic glitch in the screen.

Confirmed. It depends on some pretty complex behavior, but I'll have a fix in svn soon.

I found a bug in Pokemon Crystal (latest SVN revision as of today #53 I think), the game plays slow and the sound is terrible, the same ROM works fine on VisualBoyAdvance. I tried with Zelda DX and everything was fine with that game.
I used the SDL version BTW, I haven't tried QT because I don't want to install KDE libraries.
The emulator seems nice, I can't wait to try it when you add more features like Gamepad support and configuration files to store roms and saves paths.
Keep up the good work

EDIT: Retried Zelda DX and the sound got messed up there too, It only worked fine the first time I tried, I closed any other programs that might be interfering with the sound but the problem persists.

Could you try latest svn? If it's still there, try changing "SDL_Delay(1)" to "SDL_Delay(0)" in gambatte_sdl.cpp. BTW, you don't need KDE libraries for the Qt version. Only Qt4. KDE doesn't even use Qt4 yet (not in any stable releases anyway).

[OmegaX]

SVN revision 55 works for me now, thanks .

[tetsuo55]

Wow this is very good news indeed!!

When your emulator has some more features, and you are confident it should be hardware accurate i could do a runthrough of the first 5 minutes of every game ever officially released (no-intro).

Could you explain how accurate the emulation currently is? and do you use any of byuu libs like cothreads?

[sinamas]

Could you explain how accurate the emulation currently is?

In a word, no. My collection of corner-case hardware tests backing it up currently counts 1250 files, but accuracy isn't something you can easily quantify. As a somewhat related digression, suppose you were to prove that the emulation was 100 % accurate in all cases. With a max ROM size of 8 MB, you'd have to do 2^67108864 tests (for one mbc), which is a much, much greater number than the currently most popular estimated number of particles in the (observable) universe .
Anyway, I'm not compromising accuracy anywhere, but there are still some things to work on.

and do you use any of byuu libs like cothreads?

No. The core emulation library is intended to be pure platform-independent C/C++, so using cothreads is not an option.

It depends on some pretty complex behavior, but I'll have a fix in svn soon.

Commited.

[byuu]

No. The core emulation library is intended to be pure platform-independent C/C++, so using cothreads is not an option.

Well, sadly the only function in libco that can't be written in C++ is ~10 opcodes long. It's 10,000x more portable than SDL (which obviously isn't part of the core); yet to date, nobody has ever ported it.

It's a terrible match for the GBC anyway. The system has only one pure CPU. Honestly it's not even a good match for the SNES. I just really like eliminating enslavement and state machines in my code.

Enough about my stuff already! sinamas, have you considered writing up any technical articles on the tricks you use to achieve the accuracy that you have? I'm sure a lot of us would be very interested in reading about that. I'm also curious what makes your executable size so large? Do you perform super heavy inlining and loop unrolling or something?

[sinamas]

have you considered writing up any technical articles on the tricks you use to achieve the accuracy that you have? I'm sure a lot of us would be very interested in reading about that.

I don't know, maybe when the code is a bit more mature. I'm sure it's nothing that unique anyway.

I'm also curious what makes your executable size so large? Do you perform super heavy inlining and loop unrolling or something?

Haha, no . The windows executable is so large because it's statically linked to Qt. The linux binary is about 300K.

[Thristian]

Here's the patch I had to apply to get the latest SVN revision to compile cleanly on my OS X box (SDL only, life's too short to mess with Qt):

Code: Select all

diff --git a/gambatte_sdl/src/gambatte_sdl.cpp b/gambatte_sdl/src/gambatte_sdl.cpp
index d5fe6d5..294f7e5 100644
--- a/gambatte_sdl/src/gambatte_sdl.cpp
+++ b/gambatte_sdl/src/gambatte_sdl.cpp
@@ -17,7 +17,7 @@
  *   59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.             *
 ***************************************************************************/
 #include <gambatte.h>
-#include <SDL/SDL.h>
+#include <SDL.h>
 #include <string>
 #include <sstream>
 
@@ -302,6 +302,8 @@ int main(int argc, char **argv) {
        SDL_Quit();
        delete []sndBuffer;
        delete []tmpBuf;
+
+       return 0;
 }
 
 static void fill_buffer(void *const buffer, Uint8 *const stream, const int len) {
diff --git a/gambatte_sdl/src/syncfunc.cpp b/gambatte_sdl/src/syncfunc.cpp
index 5e43d44..4c9f74d 100644
--- a/gambatte_sdl/src/syncfunc.cpp
+++ b/gambatte_sdl/src/syncfunc.cpp
@@ -18,7 +18,7 @@
 ***************************************************************************/
 #include "syncfunc.h"
 
-#include <SDL/SDL.h>
+#include <SDL.h>
 
 namespace SyncFunc {
 struct timeval {

Now I guess it needs some kind of a config system so I can set up my favourite keybindings...

[sinamas]

Here's the patch I had to apply to get the latest SVN revision to compile cleanly on my OS X box (SDL only, life's too short to mess with Qt)

Applied. Thanks.

Code: Select all

-#include <SDL/SDL.h> 
 +#include <SDL.h>

SDL includes are commonly installed under $INCLUDEDIR/SDL, but sdl-config adds it to the include path anyway, so that's fine.

Code: Select all

+       return 0;

Which compiler are you using that requires that anyway?

[Thristian]

Code: Select all

+       return 0;

Which compiler are you using that requires that anyway?

Well, 'require' might be a bit much, but it complains about 'control reaches end of non-void function' otherwise, and it seemed a sensible thing to add.

Code: Select all

gcc version 4.0.1 (Apple Computer, Inc. build 5363)

[blargg]

Any conforming C++ compiler should complain, since your main really isn't called "main" due to a nasty macro in SDL.h which renames it to something else. Different name->default "return 0" doesn't apply.

There are some other issues but oddly I can't get GCC to flag them, even with all warnings on. One of them is use of std:: names without the std:: prefix and without a using directive. Apparently some GCC headers incorrectly bring std names into the global scope even if you never include the old C-style .h header. Thus these errors are hidden when you compile with GCC. For example, your code uses time_t in many places yet doesn't #include <time.h> (it only #includes <ctime>). Same applies to several uses of memcpy() and friends from <string.h>, even though you only #include <cstring>.

I've got many fixes and failed validation tests coming down the line, but I'm still waiting to run the sound ones on different versions of the Game Boy to confirm it's not behavior peculiar to mine (CGB-02).

[sinamas]

There are some other issues but oddly I can't get GCC to flag them, even with all warnings on. One of them is use of std:: names without the std:: prefix and without a using directive. Apparently some GCC headers incorrectly bring std names into the global scope even if you never include the old C-style .h header. Thus these errors are hidden when you compile with GCC. For example, your code uses time_t in many places yet doesn't #include <time.h> (it only #includes <ctime>). Same applies to several uses of memcpy() and friends from <string.h>, even though you only #include <cstring>.

I noticed that at a point, but turned my head and forgot about it. It's clearly something that should be fixed.

I've got many fixes and failed validation tests coming down the line, but I'm still waiting to run the sound ones on different versions of the Game Boy to confirm it's not behavior peculiar to mine (CGB-02).

Sounds great! The sound area could definitely use more testing. I did some rough testing using a pd diagnostics ROM, which' origin I'm not sure of, named "sound.gb". Lord_Nightmare's GBSOUND.txt has also been a great help, but I left a few things out for later validation. Another obvious area is OAM DMA, which I haven't gotten around to yet. I'd also like to do some weird sprite overlap tests and more mid-scanline stuff. Then there are weird things like writing to the LY-reg and other stuff.

[bobthebuilder]

sinamas, have you ever considered using blargg's Game Boy PAPU sound chip emulator. Only reason I ask, is because a few projects use it and it would make finding bugs easier/quicker.

[sinamas]

I haven't really looked into it, but it's probably pretty solid considering the author.


Anyways, 0.2.0 is out.

Release notes:
http://sourceforge.net/project/shownote ... _id=203791