OK. More interestingly: with the bit 0 of the Input Status register inverted and the CPU set to 7800 cycles(80386@33MHz) in IPS clocking mode, the display of Jazz in the level (and the surrounding area) becomes incorrect 100% of the time. The area that's displayed seems to shift in and out of the screen at both sides as I move Jazz around, like the way the surrounding area of games are loaded when running around(so effectively, you see everything that's out of bounds instead of what's inside the bounds)...
So I'm actually seeing the shifting area that's being shifted into/out into instead of the area Jazz is in(so everything left of the screen area and right of the screen area. Same with top and bottom).
If you would picture the active display as an rectangle, you would essentially see everything left, top, bottom and right of said rectangle(probably just everything to the right and bottom). So as you move left, the right side gets updated with new pixels, inverse for moving right. And as you move up, the bottom part gets updated and the same for moving down(the top gets updated).
So it looks like I'm actually looking at the second window that's being scrolled inside view, instead of the window I'm supposed to look at?
Essentially what happens in the gif at https://wiki.nesdev.com/w/index.php/PPU_scrolling . I see what's at the top right half of the gif, instead of what's at the output part?
- The start address is reloaded into a cache when vertical retrace starts.
- The remainder of the settings(byte panning, preset row scan, pixel shift count, pixel panning mode, split screen start scanline) are loaded into a cache when vertical retrace ends. Before, said caches were nonexistent and would affect data being rendered constanly on each 0th scanline(of the top and bottom window).
The only thing that is currently working correctly is the bar at the bottom(the independent window, which forces all above settings to 0).