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.

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

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

That would be great, as I'm currently trying to figure out why am I missing that first line.

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 ><

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.

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

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.

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.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum