Eckhard Stolberg

Omegamatrix, on Mon May 14, 2012 8:05 PM, said:

OK, I finally had some time to try the NTSC binary on one of my PAL Jrs again, and I can confirm your findings.

On the first test with RESP0 set to 1 the screen sank and shifted when I changed RSYNC from 37 to 38 though. But when I changed it back to 37 the screen was still in the same position until I changed RSYNC to 36. Also when I'm counting RSYNC upwards the top of the screen gets skewed more and more to the right. This is until RSYNC 38, when the top of the screen gets skewed to the left. Changing it back to 37 still has the top of the screen skewed to the left. At 36 it gets back to right.

One of my Eishockey-Fieber carts is like that too. I got it at a local flea-market several years ago. Since we had a Quelle store here, I suppose that's where it came from. The label is the same as on the normal Quelle carts. The case is similar to the black Homevision carts and the German label version of Parker Frogger. The lines on the sides and the dust cover mechanism is the same, but the Frogger cart also has lines on the back, while my Homevison 4 neither has the lines nor the 1234 on the back.

Omegamatrix, on Sun May 6, 2012 11:42 PM, said:

That's true, but as you pointed out, writing $03 into the HMPx registers is the same as writing $00. Therefore writing $00 into HMP0 later doesn't change anything. Even though the write occurs during the time where the HMOVE updates are still in progress, it has no effect, since no HMOVE pulses are fed into the position counter for player 0.

OK, I did a quick test of both binaries on one of my PAL Jr. consoles. It also is a late model which has problems with Kool Aide Man, but I don't expect any differences in running your demos on different versions of the TIA. The differences with those are mostly in how they react to HMOVE pulses that happen during the visible part of the screen, which your demo doesn't use. Triggering RSYNC in the first 24 CPU cycles after an HMOVE might be worth trying out too though.

When I run the NTSC demo, I also get a rolling screen at RSYNC on cycle 22 too. In the PAL demo this happens at cycle 38. In both demos the screen occasionally gets stable at these RSYNC counts depending on when RESPx gets hit.

I did experience PAL colour loss in both demos, but couldn't find a pattern for when it did or didn't happen depending on when RSYNC and RESPx got hit.

When RSYNC gets hit at cycle 24 or later the first couple of lines at the top of the screen get shifted to the side a bit. It's more visible in the NTSC version on my TV, but happens in both versions.

The objects always get positioned three pixels further to the right after a WSYNC than they do after a RSYNC, but this is to be expected. Triggering WSYNC will halt the CPU until the horizontal sync counter wraps around to zero. Triggering RSYNC will reset the horizontal sync counter to zero immediately. But the warp-around will actually happen after one more cycle of this counter. Since the horizontal sync counter counts once every 4 pixels, one more CPU cycle occurs before the counter warps around to zero. Therefore the positioning code will hit RESPx one cycle sooner after a RSYNC than after a WSYNC.

stephena, on Wed May 2, 2012 3:49 PM, said:

The difference is that the other games all do a WSYNC again before positioning the players. Therefore Stella knows where in the line it is supposed to be when RESPx gets triggered. I think RSYNC is the same as WSYNC except that the CPU isn't halted, because the new scanline starts immediately.

When you look at the loop at L13AF you'll notice that it triggers RSYNC 10 cycles or 30 pixels (I miscounted the loop in the last post) after it triggers WSYNC. This effectively starts a new scanline, which Stella doesn't notice, because it doesn't handle accesses to RSYNC. The emulator still counts it's current position in the line from the WSYNC not from the RSYNC. Therefore it positions the players 30 pixels too far to the right.

To fix the problem in Stella you could execute the same routine for RSYNC as you do for WSYNC. But since you don't have to halt the CPU emulation, you only need to render the current scanline to the position where the RSYNC happens and fill the rest with black pixels before resetting the TIA emulation for the next scanline.

I'm sure there are plenty of sideeffects when triggering RSYNC in the middle of the scanline, but since almost all current games only trigger RSYNC during their initialization loop, I guess Fatal Run would be the only one that might have problems with changing Stella this way.