Gambatte 0.5.0-wip2 released

[sinamas]

Thristian was imprecise. It's actually 'ints are wider than 16 bits' assumptions as the commit log says. Standard C/C++ only specifies a minimum range of (0 to 65535) -32767 to 32767 for (unsigned) ints. I'm getting rid of fixed width dependencies, and I thought I might as well improve on this too while I'm at it. I'm busy with exams, so there won't be a lot of updates for a while.

[Thristian]

So, I think I've found at least one bug in Gambatte, although only in a homebrew app.

Steps to reproduce:

• Download the demo version of LSDJ 3.1.9
• Load it into Gambatte (I used gambatte_sdl built from r111 on Mac OS X 10.4.11)
• Wait for the startup-ad to disappear. You should get to a blue screen with a vertical column of hex digits (00 through 0F), four columns of dashes (--) and some info in red on the right-hand side.
• Look at the first column of the "00" row.

Expected results: "--" highlighted in a different colour.

Actual results: Two black squares.


There's a workaround for this bug, let's go fix it:

• Hold down SELECT and tap Up on the +-pad. You should arrive at an options screen headed "PROJECT (NEW)". The first item, "TEMPO" should have black squares next to it.
• In the third group of options, "LOOK" should currently be set to "Y2K / AMI".
• Tap Down on the +-pad until "Y2K / AMI" is replaced with black squares, then hold A and tap Right to change the colour scheme. It should switch to "Y2K / CAT". Let go of A, then hold it again and tap Left to switch back to "Y2K / AMI" again. This time, it sets up the colours properly, and you can actually see what you're doing.

Here's the second bug (continuing on from the state above):

• Tap Up on the +-pad until you highlight the 255 next to "TEMPO".
• Hold down A, and tap Left a couple of times.

Expected results: While holding down A, tempo decrements for each press of Left.

Actual results: While holding down A, tempo only decrements the first time you hit Left. You have to release A and hold it again to decrement a second time.

KiGB v2.0.4 for OS X (based on v2.0.2 for PC, apparently) gets it right. I can't test it on hardware myself, but this method of editing fields is kind of important to the app, and given the number of chiptune musicians who use this software on real Gameboys on a regular basis, I'm sure real hardware behaves like KiGB. Interestingly, Goomba on GBA seems to have exactly the same problems as Gambatte, and on the LSDJ wiki the author says "Goomba can't run LSDJ v3 and up because of SRAM incompability!"

[sinamas]

I'll have a look at it when I get the time. There's a good chance that it depends on typical flashcart-specific features, while claiming to use a known mbc, like so many other homebrews.

[Thristian]

My apologies - the second bug I mentioned (lack of key-repeat) does indeed seem to be a flash-cart issue: LSDJ's "reset SRAM to defaults" command sets up key-repeat properly along with other things like a sensible default tempo.

The first bug (wrong colours at startup) still seems Gambatte-specific, though.

[blargg]

I wonder if that software depends on the initial palette values that the CGB boot ROM sets up.

[sinamas]

That wouldn't be a problem. Dependency on the colors a flashcart boot ROM sets would.

[Panzer88]

have you looked into providing system linking capabilities either by running two windows of the emu simultaneously and allowing a system link, and also to another user using the emulator online.

[Thristian]

As of revision 112 (the Christmas Day update), gambatte no longer builds for me on OS X with g++ 4.0.0; linking dies with the following error:

Code: Select all

/usr/bin/ld: Undefined symbols:
Memory::COUNTER_DISABLED

Sure enough, memory.o in libgambatte.a has that symbol undefined, and since nothing else defines it, I can't link against libgambatte.a.

The following hack fixes it, at the expense of a few warnings:

Code: Select all

--- a/libgambatte/src/memory.h
+++ b/libgambatte/src/memory.h
@@ -36,7 +36,7 @@ class Memory {
        enum events { HDMA_RESCHEDULE, DMA, INTERRUPTS, BLIT, UNHALT, END };
        enum irqEvents { /*MODE0, MODE1, MODE2, LYC,*/ TIMA, /*M0RESC,*/ SERIAL };
        
-       static const unsigned long COUNTER_DISABLED = 0xFFFFFFFF;
+       enum counterValue {COUNTER_DISABLED = 0xFFFFFFFF};
        
        unsigned char memory[0x10000];
        unsigned char vram[0x2000 * 2];

There's probably a better way to do it, though.

[bungiefan]

I'm having a slight problem trying to switch to this emu. My saves from kigb aren't loading intact. I've not had a problem with emulators for other consoles loading the same save files. Are these not compatible with each other? Are they ever planned to be?

[sinamas]

problems with lsdj3_1_9_demo.gb

FWIW the same problems are present on my GBC depending on the contents of SRAM. There may be better choices for SRAM init values than what I'm currently using. If anyone has a clue about that, I'd like to hear it.

have you looked into providing system linking capabilities either by running two windows of the emu simultaneously and allowing a system link, and also to another user using the emulator online.

Would be cool, but it's fairly low on the priority list atm.

As of revision 112 (the Christmas Day update), gambatte no longer builds for me on OS X with g++ 4.0.0; linking dies with the following error:

Code: Select all

/usr/bin/ld: Undefined symbols:
Memory::COUNTER_DISABLED

Sure enough, memory.o in libgambatte.a has that symbol undefined, and since nothing else defines it, I can't link against libgambatte.a.

The following hack fixes it, at the expense of a few warnings:

Code: Select all

--- a/libgambatte/src/memory.h
+++ b/libgambatte/src/memory.h
@@ -36,7 +36,7 @@ class Memory {
        enum events { HDMA_RESCHEDULE, DMA, INTERRUPTS, BLIT, UNHALT, END };
        enum irqEvents { /*MODE0, MODE1, MODE2, LYC,*/ TIMA, /*M0RESC,*/ SERIAL };
        
-       static const unsigned long COUNTER_DISABLED = 0xFFFFFFFF;
+       enum counterValue {COUNTER_DISABLED = 0xFFFFFFFF};
        
        unsigned char memory[0x10000];
        unsigned char vram[0x2000 * 2];

There's probably a better way to do it, though.

I don't see why that symbol would need to be exported at all. Compiler bug? Anyone? I guess I could just get rid of the inline function that needs it there.

I'm having a slight problem trying to switch to this emu. My saves from kigb aren't loading intact. I've not had a problem with emulators for other consoles loading the same save files. Are these not compatible with each other? Are they ever planned to be?

I don't see any reason why saves from kigb wouldn't work (not that I know for sure how kigb formats its saves). I assume you copied the save files from kigb's save folder to gambatte's save folder.

[Nach]

I don't see why that symbol would need to be exported at all. Compiler bug?

IIRC, in the book Effective-C++, it mentions older compilers had a problem supporting code like that properly, and to use the enum trick.

[blargg]

At least it used to be that you had to define all static members of a class, regardless of type:

Code: Select all

class Foo {
    static const int x = 1234;
};

const int Foo::x; // required

[sinamas]

At least it used to be that you had to define all static members of a class, regardless of type

Omitting the definition is supposedly legal for static constants of integral type as long as you don't take the address.

edit1: The requirement of a definition in this case used to be a defect in the standard, but has been corrected according to http://www.open-std.org/jtc1/sc22/wg21/ ... ts.html#48
edit2: Reading that again, I'm not really sure what to think. Greg Comeau ( http://gcc.gnu.org/ml/gcc-help/2005-10/msg00103.html ) and Effective C++ seem to agree though.

IIRC, in the book Effective-C++, it mentions older compilers had a problem supporting code like that properly, and to use the enum trick.

*digs through pile of books*

You're right, it suggests either that, or just giving a definition. I don't like using an enum in this case, since enums are restricted to the domain of an int AFAIK.

[DataPath]

Sinamas, how stable is the libgambatte API? Should it be pretty safe to write our own UI's for it?

I see you've been writing a lot of tests lately, which bodes well for compatibility. Any other areas that you plan on improving in gambatte?

[Nach]

Should it be pretty safe to write our own UI's for it?

Why would you want to?

[sinamas]

Sinamas, how stable is the libgambatte API? Should it be pretty safe to write our own UI's for it?

I see you've been writing a lot of tests lately, which bodes well for compatibility. Any other areas that you plan on improving in gambatte?

Not stable at all, could be changed on a whim.

After I'm done doing some accuracy work I'll be adding save states at least. I'd also like to replace the current sound resampling with band-limited sound synthesis ( http://www.slack.net/~ant/bl-synth/ ) if practically possible. That may take a bit of time though, if I decide to do it, since I don't think I'll be using blargg's blip-buffer without modifications. If I get myself set up with an accessible OS X environment I'll probably do a core audio driver and other stuff to make an OS X port more usable. Progress is slow since I'm really busy lately. The accuracy work tends to swallow up a lot more time than work on features in general.

[Panzer88]

that's perfectly acceptable as this IS an accuracy emulator. the audio stuff sounds interesting, keep us posted.

[DataPath]

Should it be pretty safe to write our own UI's for it?

Why would you want to?

Gambatte has been ported to Maemo (Nokia Internet Tablets). The current setup uses gambatte_sdl, and a python frontend. I'm writing a GTK UI to make it integrate better with the whole system.

No big deal if it changes a lot - just wondering what to expect. As long as you keep an sdl version around, it should be pretty easy to convert.

[Marty]

I don't like using an enum in this case, since enums are restricted to the domain of an int AFAIK.

Assuming you mean signed int then no.. that's only true for C but not for C++. In C++ the underlying type can be any integral type according to section 7.2.5 in the standard. Unfortunately, some C++ compilers like MSVC are broken in this regard.

Code: Select all

enum
{
  V = ULONG_MAX
};

if (0 < V)
{
  // celebrate with beer
}
else
{
  int goodbye = 0 / 0; 
}

[sinamas]

Right you are! I guess I'll just have to ignore MSVC for now then. I'm sure they'll catch up eventually.

Omitting the definition is supposedly legal for static constants of integral type as long as you don't take the address.

edit1: The requirement of a definition in this case used to be a defect in the standard, but has been corrected according to http://www.open-std.org/jtc1/sc22/wg21/ ... ts.html#48
edit2: Reading that again, I'm not really sure what to think. Greg Comeau ( http://gcc.gnu.org/ml/gcc-help/2005-10/msg00103.html ) and Effective C++ seem to agree though.

The relevant defect is actually covered here apparently: http://www.open-std.org/JTC1/SC22/WG21/ ... s.html#454
Since its status is "WP", I guess it can't be considered part of the standard yet.

[pagefault]

Hi sinamas, I don't think we have ever formally talked before, but I like your work a lot and I appreciate what you do for the scene. I was wondering if we could borrow some snippets of code from your emulator relating to Qt since we are redoing our emulator's GUI with it and it works very well with what you have.

[byuu]

Gambatte has been ported to Maemo (Nokia Internet Tablets). The current setup uses gambatte_sdl, and a python frontend. I'm writing a GTK UI to make it integrate better with the whole system.

Be sure to release your GTK+ port for Debian/amd64, please. I hear Nach really loves the GTK+ file open dialog window ;)

Right you are! I guess I'll just have to ignore MSVC for now then. I'm sure they'll catch up eventually.

If you were meaning to ignore false warnings and false errors ... I usually try and keep MSVC support working, solely because it actually can point you to some genuine errors that get ignored when you use GCC with their extensions enabled. And you can't disable said extensions in MinGW without disabling lots of important POSIX functions.

Perhaps a subtle jab ifdef would help? #if defined(REDMONDS_CPP98_INTERPRETATION) ... #endif

If I get myself set up with an accessible OS X environment I'll probably do a core audio driver and other stuff to make an OS X port more usable.

I hear OS X supports OpenAL quite well. If you'd like, the driver Nach wrote for it is PD code. And it'll benefit your Linux users, too :)

[sinamas]

Hi sinamas, I don't think we have ever formally talked before, but I like your work a lot and I appreciate what you do for the scene. I was wondering if we could borrow some snippets of code from your emulator relating to Qt since we are redoing our emulator's GUI with it and it works very well with what you have.

Sure, just don't come crying to me if it makes ZSNES eat kittens or something. I don't mind helping out if you've got questions though, and I surely don't mind cooperating where it makes sense, but my time is too limited to make lots of promises currently. I do plan to refactor the Qt code and decouple it more eventually (as well as add more features), I just can't make any promises for when I'll get around to it. It's currently clearly written without much concern for others' needs.

Anyway, if you can find something useful, I think that's great actually. I've been using ZSNES from at least version 0.300 or so. There's no reason why I wouldn't be happy to somehow contribute to making ZSNES better.

And, of course, as long as you don't need licensing exemptions there's really no need to ask formally anyway (as I'm sure you're aware).

Gambatte has been ported to Maemo (Nokia Internet Tablets). The current setup uses gambatte_sdl, and a python frontend. I'm writing a GTK UI to make it integrate better with the whole system.

Be sure to release your GTK+ port for Debian/amd64, please. I hear Nach really loves the GTK+ file open dialog window

(*off to read new article*)

Just thought I'd say I think it's really cool if you're able to make it run well on something like that. I'm actually kind of surprised it runs full speed at all (and software scaled even).

If you were meaning to ignore false warnings and false errors ... I usually try and keep MSVC support working, solely because it actually can point you to some genuine errors that get ignored when you use GCC with their extensions enabled. And you can't disable said extensions in MinGW without disabling lots of important POSIX functions.

Perhaps a subtle jab ifdef would help? #if defined(REDMONDS_CPP98_INTERPRETATION) ... #endif

I don't think there will be any errors, since every comparison dealing with that constant is unsigned anyway. I think I'd rather use the slightly less efficient alternative than add an ifdef though.

I hear OS X supports OpenAL quite well. If you'd like, the driver Nach wrote for it is PD code. And it'll benefit your Linux users, too

I haven't really looked at OpenAL much. I'd like to have detailed buffer status information during playback if possible, since I can make use of that to avoid underruns, shortened frames, prolonged frames etc. If OpenAL provides that it may well be worth prioritizing.

[pagefault]

And, of course, as long as you don't need licensing exemptions there's really no need to ask formally anyway (as I'm sure you're aware).

I know but I like to ask anyway.

[byuu]

I haven't really looked at OpenAL much. I'd like to have detailed buffer status information during playback if possible, since I can make use of that to avoid underruns, shortened frames, prolonged frames etc. If OpenAL provides that it may well be worth prioritizing.

OpenAL is a lot better than most APIs for this, but it's not perfect.

Basically, OpenAL works via buffer queues. You can attach queues of any number of samples at any frequency rate whenever you want. You probably don't want to go crazy buffering too much (obviously -- you'll have bad latency if you do.) You can read back how many buffers have completed since you last asked, and then unqueue them and reattach them to the end of the stream again. If no buffers have finished, you'll probably want to make the program sleep for a while. Maybe check on video and vsync status.

So, it doesn't give you an exact "I'm at this sample" playback cursor like DirectSound, but if you make your queues small enough and quantiful enough, you can almost certainly get the precision you need.

If you want, the API is still fresh on my mind, I'll be glad to help you write a driver for it for gambatte; at your convenience, and only if you want to, of course.