Tracing the behaviour of 'illegal' VSYNC handling in Stella

[+stephena]

Ok, a bug has been reported in Stella with ROM "Pick & Pile". This is a PAL ROM, and as such I'm unable to test it. If someone with a PAL machine and a Harmony could test it and let me know, it would be great. Otherwise I'll have to work from the code itself. The problem is, there's horrible flickering on the startup screen (once you get into the game, it's a steady 312 scanlines). In Stella, the startup screen alternates between frames with 314 lines and 4 lines. The flickering is because a 4 scanline frame is essentially blank, so every second frame is black, and hence everything flickers (sort of like 30Hz flicker).

 

However, I'm not convinced the blanking is the issue. I feel that a 4 scanline frame should be blank, and this ROM shouldn't be generating such a frame at all. Other emulators I've tested display a consistent 315 lines on this screen, so I'm thinking there's an error in Stella emulation. I've traced it to VSYNC handling (or at least I think I have). I ran the ROM and set a breakpoint at $75A7. This results in the following section of code:

 

 

The code is as follows, with a printout of Stella state after each line has executed. You can try running it yourself to confirm:

 

75A7:  LDA	#$02   ;2   // scan=311
75A9:  STA	VSYNC  ;3   // vsync set @ 311
75AB:  STA	WSYNC  ;3   // scan=312
75AD:  STA	VSYNC  ;3   // vsync set @ 312
75AF:  STA	WSYNC  ;3   // scan=313
75B1:  STA	VSYNC  ;3   // vsync set @ 313
75B3:  STA	WSYNC  ;3   // scan=314
75B5:  STA	VBLANK ;3   // ...
75B7:  LDA	#$00   ;2   // ...
75B9:  STA	VSYNC  ;3   // CPU stopped @ 314
75BB:  RTS             ;6   // scan=0  !!!

 

After this point, it goes on to do 4 more scanlines, then starts over again. So I'm thinking the CPU shouldn't have stopped and went to scanline 0, but proceeded to process a few more scanlines in this frame.

 

Can anyone explain what really should be happening here?

[Eckhard Stolberg]

Can anyone explain what really should be happening here?

I've tried the ROM on my PAL VCS, and it plays fine. I haven't looked closely enough at the code to tell if it should be executed like that. But if a game were to turn on VSYNC for 4 lines, then turn it off for 4 lines, and then turn it back on for another 4 lines, that would be essentially the same as turning on VSYNC for 12 lines.

 

When you turn on VSYNC you are telling the electron beam to return to the top left corner of the screen an to stay there. So during the 4 lines where VSYNC is turned off, you really are generating a blank frame. But it is only 4 lines tall, which is completely in the invisible part of a TV frame. So when you turn VSYNC back on an tell the electron beam to return to the top of of screen, the 4 line frame wouldn't have been noticeable. Therefore the code in Pick'n'Pile is the same as holding the electron beam at the top of the screen for 12 lines by turning VSYNC on for that long.

 

IIRC in z26 we simply ignored a second VSYNC when it came too soon after the first. I know that's a cheat, but it's easier than trying to deal properly with 4-line frames and works quite well.

[+stephena]

Thanks for the info. Another question though: where did the requirement of waiting 3 scanlines between VSYNC on and VSYNC off come from? I know that's what it says in the Stella programmers guide, but is there any documentation as to why? And if you specify only 1 or 2, will things still work? I don't suppose someone could create a test ROM to test this??

[Rybags]

2.5 scalines of VSync is a requirement of the TV standard. On our old consoles we round it up to 3.

 

Less or more - might or might not work, depends on the TV.

 

Most Atari machines including 8-bit computer and ST produce a VSync train where the scanlines before/after VSync are at black level and briefly go to sync level @ HSync, the VSync lines are reverse of that, HSync is at black level and the remainder of the scanline is at sync level.

 

With the TV standards, there shouuld actually be HSync midway through these scanlines but 99.9% of older TVs don't insist on it. The "odd" assortment of HSync pulses midway through scanlines is what generates interlace.

[+stephena]

Can anyone explain what really should be happening here?

I've tried the ROM on my PAL VCS, and it plays fine. I haven't looked closely enough at the code to tell if it should be executed like that. But if a game were to turn on VSYNC for 4 lines, then turn it off for 4 lines, and then turn it back on for another 4 lines, that would be essentially the same as turning on VSYNC for 12 lines.

 

When you turn on VSYNC you are telling the electron beam to return to the top left corner of the screen an to stay there. So during the 4 lines where VSYNC is turned off, you really are generating a blank frame. But it is only 4 lines tall, which is completely in the invisible part of a TV frame. So when you turn VSYNC back on an tell the electron beam to return to the top of of screen, the 4 line frame wouldn't have been noticeable. Therefore the code in Pick'n'Pile is the same as holding the electron beam at the top of the screen for 12 lines by turning VSYNC on for that long.

 

IIRC in z26 we simply ignored a second VSYNC when it came too soon after the first. I know that's a cheat, but it's easier than trying to deal properly with 4-line frames and works quite well.

 

Due to the way Stella generates its display (double-buffering), I had to use code to specifically deal with these 'short' frames. In cases where they occur, they're hidden from the display logic (since the TV wouldn't display them either), but they're still executed. I feel this accurately emulates how a real system deals with such frames, and it fixes the bug that was reported with Pick & Pile. Thanks for the info.