using Stella's debugger to analyze VSYNC

[+SpiceWare]

Yesterday @ckrtech contacted me for insight on an issue he's having with Battlezone and his new RetroTINK 5X-Pro video upscaler. The picture is unstable, as you can see in the video he tweeted this afternoon:

 

 

I suspected it was generating an invalid VSYNC signal. From Stella Programmer's Guide, available at MiniDig, we know that VSYNC should last 3 scanlines:

 

So I used Stella to check it out. Sure enough, it was just over 2 scanlines long, and had a couple other issues as well.  After sending him the results I got to thinking that others may find it useful to see how to check this.

 

 

We'll start off this investigation with Combat because it correctly generates VSYNC.

 

Launch Stella and load Combat.

Press the ` key (by 1 and tab) to enter Stella's Integrated Debugger. In the prompt type the command: trapwrite VSYNC

after hitting return you should see: added trap 00

 

 

press the ` key again to resume running the ROM. The trap should immediately return you to the debugger:

Make note of:

• Frame Cycles: 19760
• Scan Cycle: 3

 

VSYNC should be changed just after the WSYNC, so it should always occur on Scan Cycle 3.

 

Press the ` key again.

 

 

Frame Cycles is now 0 because the new frame just started. 

 

This is useless to determine the number of cycles that elapsed for the VSYNC, so we need to halt the program before the 2nd store to VSYNC occurs. To do that, locate the current instruction in the Disassembly tab, it will be outlined in a red box, then click to the left of the store to VSYNC just above it. A red dot will appear to show the breakpoint is set:

 

 

Hit ` again, should see the same Frame Cycles (19760) you saw before.

Hit ` again:

 

 

Frame Cycles: 19985
Scan Cycle: 0

 

The store to VSYNC hasn't yet occurred, so we need to know how long the instruction is going to take.  We can see that it's 3 cycles by looking at the value after the ; in the Disassembly.  Adjusting for that we know the cycles after sta VSYNC occurs will be:

 

Frame Cycles: 19988
Scan Cycle: 3

19988 - 19760 = 228.

 

There are 76 cycles per scanline and 3 * 76 = 228 so VSYNC was on for exactly 3 scanlines, which is what we expect it to be.

 

Now we'll do the same after loading Battlezone:

 

 

As before:

• Press the ` key to enter the debugger
• type the command trapwrite VSYNC
• press ` again

 

 

Frame Cycles: 19743
Scan Cycle: 64

Scan cycle of 64 is not good, it should be 3.  We can see in the disassembly it was not done after a sta WSYNC.

press the ` again, we'll end up with Frame Cycles of 0. Like before, set a breakpoint on the sta VSYNC instruction

 

 

press ` again.

 

Surprise!

 

Frame Cycles: 19741 - was expecting 19743 like before
Scan Cycle: 62 - was expecting 64 like before

 

Inconsistency is not good.

 

press ` again.

 

Frame Cycles: 19909
Scan Cycle: 2

the sta VSYNC cycle time is 3, so adjust to:

Frame Cycles: 19911
Scan Cycle: 5

 

19911 - 19743 = 168
19911 - 19741 = 170

168 / 76 = 2.21 scanlines
170 / 76 = 2.24 scanlines

If you hit ` a number of additional times you'll see the Frame cycles for the initial VSYNC varies from 19739 - 19745, so actual VSYNC duration varies from to 166 to 172 cycles. 

 

 

 

 

So Battlezone does a few things wrong when setting VSYNC:

1) VSYNC is on for less than 3 scanlines 
2) VSYNC is toggled at the wrong cycle for the scanline, it should occur on cycle 3
3) VSYNC duration varies slightly over time

I don't know which of these is causing problems with the RetroLINK 5X-Pro

[Thomas Jentzsch]

Thanks. We lately had a similar problem when switching the ports for a QuadTari. 

 

Rule of thumb: When wanting to wait for N scanlines, you have to do N+1 WSYNCs (the extra one directly before or anywhere after starting the delay) to be 100% safe. 

Edited May 5, 2021 by Thomas Jentzsch