RSYNC, repositioning, and emulation

[Omegamatrix]

I wrote a test program for RSYNC after reading about how the aliens and human in Extra Terrestrials was being positioned wrong in the Stella Emulator. More on Extra Terrestrials here:

 

http://www.atariage....e/#entry2513742

 

 

There is a PAL rom and a NTSC rom. These need to be tested on real hardware to determine how Stella should handle RSYNC. There are instructions on how to use the rom and what it does in the assembly file. My own trial was on late model Jr, and I know the TIA is not good at positioning things on it. It screws up the score in Thunderground for example. Anyhow here are instructions directly from the assembly file, an a screen shot to hopefully generate interest and get people to try it out!

 

 

Test Rsync.zip

 

 

;---------------------------------------

; HOW TO PLAY THIS PROGRAM

;---------------------------------------

 

The top green bar is an object that is positioned after a write to RSYNC. The bottom bar

is the same object, but positioned mid kernel after a write to WSYNC. The idea is to visually

compare the two to see how the Atari is handling RSYNC.

 

When the Atari is powered on this program starts in an automated mode going through every single

machine cycle combination of RSYNC and RESxx. In automated mode pressing the joytick up will

slow the speed at which the combinations are updated. Press the joystick down to speed it up again.

 

If the fire button is pressed manual mode is entered. In manual mode use the joystick to move back

and forth between the RSYNC and RESxx cycle numbers. Pressing up or down will adjust the cycle as desired.

Changes are instantly reflected on the screen. Press the firebutton again to return to automated mode.

 

In either automated or manual mode, use the select switch to change the objects on screen between

P0, P1, M0, M1, and the Ball.

 

Finally, "Reset" resets the program (no surpises there ha ha!)

[Omegamatrix]

I realized I messed up on one of my examples for scanlines. I meant to have COLUBK end at 76, and RSYNC to start on the new line. Unfortunately I can't edit my post, so I'm reposting an updated assembly file. The actual roms are still the same as before, it's just some text that doesn't get compiled that has changed.

 

Test Rsync (v2).zip

 

 

And the part that is now updated:

 

;  I opened Fatal Run in Stellas Debugger and found the VSYNC routine starting at various
;  different cycles, going in between the time outlined in the extremes cases above. The
;  scanline count in Stella's Debugger shows 261. However RSYNC starts a new scanline when
;  strobed, and RSYNC is not being handled by Stella so it can cause the scanline count to
;  be off. Lets look at another case with a focus not on VSYNC, but actual scanlines used:
;
;
;	lda	#$A0	;2  @73
;	sta	COLUBK  ;3  @76  for demostration purposes, we'll call this scanline 0...
;------------------------------
;	sta	RSYNC   ;3  @76  scanline 1, as RSYNC started a new line
;------------------------------
;	sta	WSYNC   ;3  @76  scanline 2
;------------------------------
;	sta	WSYNC   ;3  @76  scanline 3
;------------------------------
;	lda	#$00	;2  @2   scanline 4
;	sta	COLUBK
;
;
;  Because Stella does nothing with RSYNC, the scanlines are short by 1 like so:
;
;
;	lda	#$A0	;2  @73
;	sta	COLUBK  ;3  @76  scanline 0
;------------------------------
;	sta	RSYNC   ;3  @3  Stella emulator ignores RSYNC, and doesn't update scanline count
;	sta	WSYNC   ;3  @76  scanline 1
;------------------------------
;	sta	WSYNC   ;3  @76  scanline 2
;------------------------------
;	lda	#$00	;2  @2   scanline 3
;	sta	COLUBK

 

 

Thinking about it now, I wonder how many lines my code is actually running. I suspect the PAL rom might be black and white until about RSYNC count 37 or so. I experienced the screen dropping a scanline at this point on my TV. I also got some rolling around RSYNC count 22. It's late now and I don't have my Atari plugged in, so I'm going from memory. In a short summary though, for the most part the two bars didn't line up. I'm wondering if they will on other Atari's. I will post a more detailed summary of the results I saw sometime tomorrow.

[Eckhard Stolberg]

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.

[Omegamatrix]

I hooked up my Atari today and tested the rom again. I found:

 

 

For RSYNC at a set RESP0 of 1:

@ RSYNC 22 my screen rolled, and @ RSYNC 37 the screen sank and shifted to the right a little. The screen was also skewed a little.

 

For RESP0 at a set RSYNC of 1:

@ RESP0 76 the RSYNC bar (top bar) is a pixel leftward of the WSYNC bar (bottom bar). @ RESP0 1 to 22, both bars were vertically aligned. @ RESP0 23 to 75 the RSYNC bar was three pixels behind the WSYNC bar, just like Eckhard noted.

 

So, there seems to be an anomaly at RESP0 of 1. Eckhard do you see the same thing? Stephena, is this enough info to make RSYNC work in Stella?

[+stephena]

Please keep testing and reporting, it's all very helpful. But I won't get to this until after 3.7 is released, so at least another week or two.

[Eckhard Stolberg]

I hooked up my Atari today and tested the rom again. I found:

 

 

For RSYNC at a set RESP0 of 1:

@ RSYNC 22 my screen rolled, and @ RSYNC 37 the screen sank and shifted to the right a little. The screen was also skewed a little.

 

For RESP0 at a set RSYNC of 1:

@ RESP0 76 the RSYNC bar (top bar) is a pixel leftward of the WSYNC bar (bottom bar). @ RESP0 1 to 22, both bars were vertically aligned. @ RESP0 23 to 75 the RSYNC bar was three pixels behind the WSYNC bar, just like Eckhard noted.

 

So, there seems to be an anomaly at RESP0 of 1. Eckhard do you see the same thing? Stephena, is this enough info to make RSYNC work in Stella?

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.