The simpler it is, the more quirks there are. 'Tis a vicious tradeoff with the Atari VCS as the endpoint.

I was debugging Altered Space (GB) and discovered something interesting that most GB emulators get wrong (including mooneye-gb, sorry gekkio), but gambatte and BGB get right. There's no documentation on this, but it turns out that a mode 2 (OAM) IRQ does NOT fire if mode 0 (Hblank) IRQs are enabled [edit: only while in the Vdraw region, i.e. LY<144]. Altered Space relies on this behavior, frustratingly enough.

Nice find endrift

Thanks very much for this, endrift. I ran out of patience trying to figure out what was going on with Altered Space.

Ooooh, that one is nasty :)
I've actually seen this before, and can explain the basic idea why it happens.
There are multiple "sources" for STAT IRQs, and they seem to share an internal STAT interrupt flag line, and the real STAT interrupt is edge-triggered based on this line. If we only consider mode changes, this is still fairly simple, but LYC=LY coincidence complicates matters, and I'll leave it out for the moment.

Since we're only looking at modes, you can think of the internal interrupt line as if it was something like this:



Now, the actual STAT interrupt involving the normal CPU and IE/IF machinery is only fired when this internal line transitions from 0 to 1. When does that happen? For example when changing to a new mode.
This internal line is not like IF that is cleared, but more like a signal "should there be an interrupt right now", which keeps its state until the source bits change.

Let's say we start with this:



We move on to mode=3, and finally to mode=0, which changes internal_stat_irq_line to 1, which is an edge from 0 to 1 and causes an interrupt. This is quite simple, but what about:



We move on to mode=0, which triggers 0->1 transition. Regardless of whether an interrupt is actually handled (depending on IE/IF/IME), we get internal_stat_irq_line=1. Here's the interesting part: we then move on to mode=2, which has internal_stat_irq_line=1, but since it is already 1, it doesn't trigger a transition! No interrupt!

So, interrupts only happen if the internal irq line gets a chance to go to 0. Therefore we need to understand what things affect the internal line, and this is where it gets really complicated. I'm just guessing here at this point, but how about:

• Writes to STAT modeX_irq_enabled bits
• Mode changes
• If LYC=LY interrupt is enabled, current values of LYC and LY
• If LYC=LY interrupt is enabled, any written values of LYC and LY
• Whatever internally happens when entering/being inside of/exiting vblank
• Anything that changes the timings of the previous things...For example, timing of mode0, mode3, and probably even mode1 depend on current values and writes to many GPU registers and data areas

And all these with sub-M-cycle accuracy, which is needed because the behaviour depends on the precise T-cycle timing of when writes have an effect. And my research about the general GPU timings is still incomplete and we can't even accurately predict the answer to the question: when does mode=0 start?
We've already seen in the timer tests that the timer increments on transitions of certain register and counter bits, regardless of the reason of the transition. It's just the same thing here.

For example, let's imagine we have all STAT IRQ sources enabled. This means that the mode sources only allow the internal line to transition to 0 in mode=3, and LYC=LY source only if LYC!=LY. If we cleverly change LYC in sync with the LY values, we can keep the internal irq line as 1 even in mode=3, and never get an interrupt! This is just conjecture, but entirely possible.
And let's not forget that if the GPU decides to pulse some important source bit just for a single 4MHz cycle for some crazy implementation detail reason, it can cause a transition in the internal line even if the pulse is otherwise completely undetectable in normal GB code.

The interplay of different GPU things is so incredibly complicated...this is why I'm still investing in automated hardware testing and not writing and running test ROMs :)

And just to remind you about the timer...the bloody thing can increment and cause an interrupt just because you turned it off...sigh... :)

If Gambatte or BGB gets this STAT IRQ stuff right (not just the easy bits!), I'll print out all the source code of my test ROMs and eat it.

Not many bugs have stumped byuu like that. You all make the GB sound so complicated. Also, sub-cycle accuracy? Surely there isn't a game that needs that.

> Not many bugs have stumped byuu like that.

It's because nothing's ever certain on the GB/GBC. Everything is just a series of hacks and "I think this should work, but we should probably test this more."

And every time someone actually does do more tests, the entire theory changes again. And then when someone else tests it, they get completely different results. See the recent behavior to get GBVideoPlayer working, for example. I still have no clue what the proper behavior there is.

The more I've been implementing these findings, the more unstable things have been becoming. There's now a near-permanent flicker on the bottom tile row, especially in Super Game Boy mode. Coupled with the new audio resampler mysteriously adding huge latency spikes to the SGB, said mode is now practically unusuable =(

When I worked on SNES emulation, I would spend up to 2-3 weeks putting in 10 hours a day, 7 days a week, until I'd crack even the tiniest, seemingly unimportant detail, like with MDR/open-bus updates during HDMA, or I/O->read cycle shift during two-cycle CPU instructions when IRQs trigger. The theory was simple: test every last possibility, no matter how small, to make sure there's no other possible way a given behavior works. Because if you don't perfect everything as you go along, it turns into a giant mess where certain things only work because two or more things are wrong, and then when you fix one of them the right way, you think it's incorrect because an important game breaks.

Sorry, but I just don't have the energy left in me to do all this again for the GB. I also don't mean for the above to seem negative. endrift's findings and gekkio's notes are still a definite step in the right direction, and much better than we had before (Altered Space being completely broken.)

Gameboy emulation is in the state it's in, because so very few people did some research back in the day and the best estimate that many emulators do is good enough for virtually the whole game library.
You couldn't even find complete pinouts for the most common memory controllers used, so everything is mostly guess-work.

Currently, I'm working on the MMM01. Functionality is broken down to the last bit right now. Don't know if it has any function or does anything. So far, I didn't observe any changes :-/ And an exhaustive test would run for about a week straight ;)

I'm gonna contribute that to MESS in the near future.

Hold the phone, you're not Tauwasser. You didn't post his signature.