The easiest thing to do in this case is send me a diff. If you've grabbed the code from SVN, then it would be as easy as 'svn diff', or something similar in the UI-based version of SVN. I'm in the process of documenting this in a developers howto webpage.
Also, I notice your code is almost exactly the same as WSYNC, except you also add a check for >22. What is the significance of this 22??
I'm counting 6502 time in 1-76 cycles, and there are three unique areas for the bars in my test rom.
- at cycle 76 the bar moved with RSYNC is 1 pixel behind the bar moved with a normal WSYNC
- at cycles 1-22 both bars are aligned
- at cycles 23-75 the bar moved with RSYNC is 3 pixels behind the bar moved with a normal WSYNC
There are 160 pixels per line taking 160 TIA cycles, and 76*3 = 228 TIA cycles available. 228-160 = 68 TIA cycles for HBLANK, or 68/3 = 22.7 6502 cycles.
This is where the >22 comes from. At 22 cycles HBLANK is not quite complete, but at 23 cycles it is.
Why RSYNC and WSYNC are different in the first place is more elegantly explained by Eckhard in the thread with the RSYNC rom I built.
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.