Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix STAT mode when LCD is turned off #5

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Fix STAT mode when LCD is turned off #5

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion 2017-05-29-holy-grail-bugs.markdown
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,7 @@ So why does the game break so utterly the more accurate the emulator gets? No on

[^pinball-titles]: Beyond the name and logo, I'm not entirely sure what the difference between these two titles is. Furthermore, there is also the related title Pinball Dreams, but I've not investigated if this game has similar issues.

Typical speculation involves screen timing issues. The Game Boy's pixel processing unit (PPU) operates in a series of "modes" that tell the software what the PPU is currently doing. Mode 1 means that there are no scanlines currently drawing (either because it's in-between frames, or the screen itself is off), and the other modes tell the game what part of a scanline is being processed: sprites, the actual pixel data, or if it's in-between scanlines. However, various configurations of screen settings and sprites cause minute differences in the timings of these modes. The Game Boy can draw up to 10 sprites (also known as objects or OBJs) per scanline but the exact configuration of these sprites very slightly affects the timing of the PPU itself. Furthermore screen panning and "window" features also affect the timing. A scanline that has no sprites, no panning and no windows on it takes a well defined, well understood number of cycles for each of the modes. While how panning and windows affect timing is understood, once sprites are added the timings become harder to decipher. Gekkio, author of the accuracy-focused emulator [Mooneye GB](https://github.com/Gekkio/mooneye-gb), created a test suite for many of the PPU timings, including the effects of sprites, and neither BGB nor gambatte pass this test.
Typical speculation involves screen timing issues. The Game Boy's pixel processing unit (PPU) operates in a series of "modes" that tell the software what the PPU is currently doing. Mode 1 means that it's in-between frames, and the other modes tell the game what part of a scanline is being processed: sprites, the actual pixel data, or if it's in-between scanlines. However, various configurations of screen settings and sprites cause minute differences in the timings of these modes. The Game Boy can draw up to 10 sprites (also known as objects or OBJs) per scanline but the exact configuration of these sprites very slightly affects the timing of the PPU itself. Furthermore screen panning and "window" features also affect the timing. A scanline that has no sprites, no panning and no windows on it takes a well defined, well understood number of cycles for each of the modes. While how panning and windows affect timing is understood, once sprites are added the timings become harder to decipher. Gekkio, author of the accuracy-focused emulator [Mooneye GB](https://github.com/Gekkio/mooneye-gb), created a test suite for many of the PPU timings, including the effects of sprites, and neither BGB nor gambatte pass this test.

However, [SameBoy](https://github.com/LIJI32/SameBoy) developer Lior Halphon did some investigation. By disabling certain features that affect scanline timings and comparing behavior in SameBoy with behavior on a Game Boy Color he determined that scanline timings were likely not the culprit. In fact, while experimenting with timing of other portions of the system Lior and I temporarily introduced many incorrect behaviors, mostly involving interrupts, each one seemed to fix the game. But all of these behaviors was incorrect and would undoubtedly break other games.

Expand Down