ZSNES board

Last I checked, latest public revision is r243 Sun Apr 4 16:17:40 2010 UTC. http://gambatte.svn.sourceforge.net/viewvc/gambatte?view=revision&revision=243 Both gambatte_sdl, and gambatte_qt build just fine here on Debian gcc version 4.4.5. That patch does nothing as gambatte_sdl.cpp already incl...

I figured you'd be happy to hear that. I'd also like to welcome byuu to the direction of accurate, maintainable, and fast as fuck. Thanks for the news on that.

They involve a more thoroughly reverse-engineered PPU than I'd thought feasible. And cleaner code.

Not dead. Major rewrites going on.

Tallgeese wrote:Is there any particular reason this emulator flat out refuses to load any kind of Robopon GBC game?

And I mean any version. Moon, Star, Sun... English, Japanese? None load.

Probably because no one requested HuC3 support.

Before we move on to Part 3,I'd like to report a few DMG core bugs in the latest version of Gambatte: - The first three lines of the displayed image are flashing when a sprite touches them.A lot of games are affected. Beetlejuice extracted from bgb or the real hardware: http://stashbox.org/280685/b...

It's getting there.

If you want speed, you should at least unroll it. unsigned log10(const uint_fast64_t in) { #define POW10M1_4(n) Pow10<n>::R - 1, Pow10<n+1>::R - 1, Pow10<n+2>::R - 1, Pow10<n+3>::R - 1 #define POW10M1_8(n) POW10M1_4(n), POW10M1_4(n+4) static const uint_fast64_t cmpt[] = { POW10M1_8(0), POW10M1_8(8),...

slightly moar evil / less suck template<unsigned pow> struct Pow10 { enum { R = Pow10<pow-1>::R * 10ULL }; }; template<> struct Pow10<0> { enum { R = 1ULL }; }; unsigned log10(const uint_fast64_t in) { #define POW10M1_4(n) Pow10<n>::R - 1, Pow10<n+1>::R - 1, Pow10<n+2>::R - 1, Pow10<n+3>::R - 1 #def...

bah template<unsigned pow> struct Pow10 { enum { R = Pow10<pow-1>::R * 10ULL }; }; template<> struct Pow10<0> { enum { R = 1ULL }; }; unsigned log10(const uint_fast64_t in) { #define POW10M1_4(n) Pow10<n>::R - 1, Pow10<n+1>::R - 1, Pow10<n+2>::R - 1, Pow10<n+3>::R - 1 #define POW10M1_8(n) POW10M1_4(...

About progress: I _have_ been able to do some basic DMG testing, which indicates that the DMG and CGB differ in a few core areas, but are otherwise very, very similar. Unfortunately a lot of my tests depend on some of that CGB-specific behavior, so they need to be reworked to be meaningful for the ...

crocomire wrote:I found a "sprite bug" similar in Metroid II...

Looks normal to me. On the DMG sprites further to the left have priority. Since both Samus and the ball are composed of several sprites, which ones appear on top will depend on Samus' horizontal position.
Thanks for the feedback.

sinamas: I think I found a bug. It happens on both my CGB and DMG-08. Many games get that when the sprite limit is exceeded. I actually had to hack the ROM image to get it to run on my flash cart, as it depends on MBC1 behavior that conflicts with the MBC5-ish behavior of my flash cart. About progr...

That's not generating it automatically, you're still explicitly instantiating all the combinations in the table declaration. However, with some additional setup you might be able to nest the instantiations at compile time and make the growth linear instead of exponential. If you can't do it cleanly...

New release . It contains a few important bug fixes, such as MBC2 ROMs not getting any SRAM in 0.4.0. It also contains some major audio/video timing improvements, as well as improvements and additions to platform-specific audio/video engines (particularly on win32). The verbose log: libgambatte: - ...

blargg wrote:sinamas, if you keep track of the absolute time of the last event, inserting an event past all the others can done in constant time.

True, but we still get linear complexity on average if the common case position is before the end and has a mean proportional to N.

Suppose you have N events, and that every time an event is executed it is rescheduled to execute after all the other events (but we don't know this, so we can't just stick it to the back of a FIFO). Then with a delta queue approach each event execution+rescheduling has O(N) complexity. Amortizing ov...

Good point, ecst. I use that in my gettime/sleep abstraction code for instance, but haven't applied it to this for various reasons.

Ah, that brings up two problems for me: 1) you have to test each and every entry in the list when adding time (at least when its possible for those events to fire.) No idea what you're talking about here. Are you perhaps confusing a heap with something else? With a binary heap adding cycles would b...

I use either a heap with absolute times Won't that require decrementing and checking every item in the list? No, I keep a single cycle counter that is incremented and compared to the head. The event time is the count at which the event is supposed to occur. EDIT: what do you mean by "the list&...

I use either a heap with absolute times or, if there is a very low number of fixed events, I just statically select the closest event linearly on changes, avoiding looping/indirection overhead (the low constant factor benefit outweighs the O(n) penalty for low n) but having to write the selection fu...

Try putting this part: //this part is hit one in 680 calls, so optimizing it won't help much status.hcounter = 0; status.vcounter++; if((region() == 0 && interlace() == false && status.vcounter == 262) || (region() == 0 && interlace() == true && status.vcounter == 263...

Most people have the opinions that are most convenient for them to have. Throughout our lives we're being conditioned to have certain things that we don't question because they're obvious things to us. Yet if a person critically analyzes some of these "obvious" opinions that (s)he's condit...

only for a few months I don't know how many months it'll be. I've got other things to do with my time too, and it'll probably be a lot of work. There are more than 1500 test files in the hwtest directory at the minute, most of which I'll have to rework. And then, depending on the nature of the diff...

I'll consider adding a command line argument.