GBVideo (Pokemon) correct emulation

Discussion of programming and development for the original Game Boy and Game Boy Color.
LIJI
Posts: 23
Joined: Mon Jan 18, 2016 5:36 pm

Re: GBVideo (Pokemon) correct emulation

Post by LIJI »

Sik wrote: More likely explanation: it fetches SCX into an internal counter (used to keep track of its current position at each pixel) and then uses that for the rest of the scanline. So changes to SCX mid-scanline go ignored precisely because it isn't even checked in the first place.
That's exactly what I thought.
Sik wrote:Do new values still remain for the next scanline though or is the write actually masked out?
I still don't have a test ROM for that, but considering somewhat similar behavior with registers related to the window (See 007 - The World Is Not Enough), I believe it is still writable.
LIJI
Posts: 23
Joined: Mon Jan 18, 2016 5:36 pm

Re: GBVideo (Pokemon) correct emulation

Post by LIJI »

Higan 0.99 fails this test too. It also misses the first line timing, meaning I'm not alone on this. :P
Attachments
scxtesthigan.png
scxtesthigan.png (18.35 KiB) Viewed 4159 times
Shonumi
Posts: 342
Joined: Sun Jan 26, 2014 9:31 am

Re: GBVideo (Pokemon) correct emulation

Post by Shonumi »

LIJI wrote: I still don't have a test ROM for that, but considering somewhat similar behavior with registers related to the window (See 007 - The World Is Not Enough), I believe it is still writable.
You want me to make a test ROM? Shouldn't take me until this afternoon. If what I have in mind works, visual confirmation should be a lot easier than staring at some of the test pictures I see floating around this thread :P
LIJI
Posts: 23
Joined: Mon Jan 18, 2016 5:36 pm

Re: GBVideo (Pokemon) correct emulation

Post by LIJI »

Shonumi wrote:
LIJI wrote: I still don't have a test ROM for that, but considering somewhat similar behavior with registers related to the window (See 007 - The World Is Not Enough), I believe it is still writable.
You want me to make a test ROM? Shouldn't take me until this afternoon. If what I have in mind works, visual confirmation should be a lot easier than staring at some of the test pictures I see floating around this thread :P
That would be great, as I'm currently trying to figure out why am I missing that first line. :P

As for a nightmarish-epilepsy-causing test image, I assumed the behavior would be more non-trivial when I wrote the test ROM, so I wanted it to contain as much info as possible. Also, basing the ROM on GBVideoPlayer didn't help making the result any simpler ><
Shonumi
Posts: 342
Joined: Sun Jan 26, 2014 9:31 am

Re: GBVideo (Pokemon) correct emulation

Post by Shonumi »

Sorry LIJI, it's taking me a bit more time to make a good test ROM. I think I've run into some unexpected behavior. What I'm trying to do is make a test pattern and change the value of SX at different points during scanline rendering. Early testing about our "SX latching" theory may need some adjustments. I can definitely write to SX during Mode 2 (OAM), but curiously Mode 0 (Hblank) seems to ignore any new values of SX. The next line isn't scrolled at all.

I don't know if that is news to anyone, but it makes sense why so many games use the LY == LYC IRQ when changing SX midscreen. A timely LY == LYC IRQ should happen during Mode 2. No idea what happens when we try writing SX during Mode 3, most likely the same as Mode 0. Don't know if that helps, or if that muddies up things even more. I'll have to adjust the test ROM to account for this, so I'll probably have something ready later during the day/night.
Shonumi
Posts: 342
Joined: Sun Jan 26, 2014 9:31 am

Re: GBVideo (Pokemon) correct emulation

Post by Shonumi »

Alright, I think this is good enough. Forget about what I said earlier. Seems you can change SX in Mode 2, Mode 3, and Mode 0 and still have it take effect on the next line. Not being able to get it working on HBlank was just my bad coding :P

Anyway, it's simple. The test ROM just shifts a fullscreen pattern by 0 or 1 every other line (the original pattern is already shifted every other line, so SX changes "correct" it). The result should create a series of vertical bars. The source code is attached as well as the ROM. Nothing fancy, but I've messed around with the OAM-STAT IRQ a few times to get it working with Modes 2, 3, and 0. Same result on real hardware. Nothing changes on the current line, just the next one. My guess is the latched value for SX is determined between the end of Mode 0 and the start of Mode 2.
Attachments
SX.txt
(3.28 KiB) Downloaded 196 times
sx_test_v1.gb
(32 KiB) Downloaded 214 times
DarkMoe
Posts: 70
Joined: Sat Jun 27, 2015 1:09 pm

Re: GBVideo (Pokemon) correct emulation

Post by DarkMoe »

mmm, I think something is still wrong with my implementation. Look at this, first line is inverted, and the rest start with black line.

What's the correct pattern for your test ?
Attachments
scrollx test.png
Shonumi
Posts: 342
Joined: Sun Jan 26, 2014 9:31 am

Re: GBVideo (Pokemon) correct emulation

Post by Shonumi »

The 1st line should be in sync with the rest. Technically, the very last pixel on some of the scanlines should be messed up as well, but I haven't pinpointed why that seems to happens on real hardware.

To me, it looks like you're applying SX = 1 to the 1st scanline. This shouldn't happen. Every even line should have SX = 0, and every odd line should have SX = 1. The only time SX is changed is in those OAM-STAT interrupts. I think what you're dealing with is some obscure (and poorly documented) behavior with the last scanline in VBlank that affects Line 0's STAT interrupts and LYC interrupts. For more info, check out Kirby's Dream Land 2's intro with LYC == 0 IRQ. Line 153 does some funky stuff, and it looks like that's at play here. Try stepping the test ROM through BGB for a closer look.
Post Reply