PPU BG rendering one dot early

[Fiskbit]

I noticed some really strange PPU behavior on a Japanese player's Twitch stream recently and am wondering if this is associated with a PPU revision or if it's some kind of hardware failure. Specifically, it looks like the PPU is starting and ending background rendering 1 dot early every scanline, resulting in a duplicated column on the left side of the screen and a missing column on the right side, with sprites being able to hang off the edge on the right.

You can see it in this clip. Whenever Link is walking off the right side of the screen, his sprite is able to extend 1 pixel further than the edge of the playfield, though the background graphics here should extend all the way to the right edge. The background isn't shifted over; rather, the graphics that should be in that column are missing, and the left edge is duplicated. The black regions on the left and right side of the screen are the screen border and correctly output the transparent color on the title screen, so the issue on the left doesn't seem to be some kind of capture problem. I did try to ask the player what hardware he was using and it sounds like it's a normal Famicom, but my Japanese and his English are pretty limited.

Is this a known issue that is perhaps tied to some hardware revision? Does this mean that one can't rely on a sprite 0 hit on that rightmost dot?

[NewRisingSun]

You cannot rely on sprite 0 hits on the rightmost dot (X=255).

(Apart from that, that clip is mysterious in many ways. I don't know if that walking off the right side of the screen to appear on the left side is some sort of minus-world-like trick that Zelda fans have known about for years or not. There is also that strange noise that sounds like termites banging against the controller.)

[lidnariq]

Does this mean that one can't rely on a sprite 0 hit on that rightmost dot?

I swear I already saw a source saying that sprite 0 hits don't work on the last dot regardless... although this could be why.

The wiki just says "for an obscure reason related to the pixel pipeline." so it seems not unlikely that this person has something predating a rev G PPU.

[koitsu]

Despite being real hardware, I kind of wonder if this is a Famiclone.

[Sour]

Sprite 0 hits not working on dot 255 has been known for a long time, afaik - it's part of blargg's tests, so presumably this is true on the vast majority of hardware?

The screen transition glitch is a known bug in Zelda that is often used in speedruns (though I had only seen it in a TAS before now)

[Fiskbit]

Thanks for the reminders that there are restrictions on where on a scanline sprite 0 hits can occur; I had forgotten about this entirely. Still interested in what's going on here, but it sounds like it's not something that would have an effect on program execution. Also, the possibility of it being some kind of clone system had crossed my mind and I can't rule it out with what I know, unfortunately. I've looked at some Famicom video capture on YouTube to see if I can find an example of the same issue there, but haven't encountered it yet.

As for the rest of the clip's contents, the sound is one-frame D-pad taps and the wrapping behavior is 'expected'. :) Perpendicular input on specific grid positions can set up a situation in which you skip a grid intersection, which bypasses a collision check and the screen edge check.

[Banshaku]

Like koitsu said, it could be a famiclone issue. It seems people are using them more and more in Japan, especially the portable one. These days it causing issues for homebrew dev since some carts don't always work as expected (some mmc3 irq counter issues) or fail to read the controller. This is causing quite a headache if you want to support original and clones. The columbus clones, which are very common, fails often ^^;;

[ccovell]

I don't really know about all Famiclones, but I noticed a bug like this in my old DrPCJr clone console. Here's what I wrote about it back then:

"The Doctor PC Jr's PPU emulation is not completely accurate and is a little quirky. The BG is offset by one horizontal pixel to the left. So, sprites and the BG are slightly misaligned. Also, when the scroll register is 0, one vertical strip of pixels of the adjacent name table is visible on the right side of the screen. Furthermore, when the sprites and BG are turned off in the left border, one vertical strip of BG is visible to the left of this border!"