Scanline variation question

[+nanochess]

Hi everybody.

 

Just I was having a doubt about scanline variation in Atari VCS.

 

Suppose we have an NTSC game with 262 lines, but once each (let us say) 5 frames, it changes to 263 lines. It would roll in a TV? This would be valid for PAL60?

 

I'm thinking that no roll would occur, because it would fit in the standard 525 lines of NTSC.

 

There is any game doing this?

 

Now another question, this time about PAL, I've noted that in Stella the screen goes gray when 313 lines happen. This happens in real console? what happens if most of time the game generates 312 lines, and only one frame each second of 313 lines. The frame would be gray?

 

[+SpiceWare]

It won't roll the screen, but it will noticeably jitter the picture up/down.

 

Yep - PAL TVs will show a monochrome image if they receive an odd number of scanlines from the Atari.

 

As such it's best practice to always output a consistent number of scanlines, and always have that number be even.

[Nukey Shay]

Some modern adapters will apparently freeze the image from that point on (making the issue a game-killer).

[Mr SQL]

NanoChess,

my ASDK framework was doing this in one of it's kernels. OmegaMatrix fixed the bug by adjusting the timer delay values

 

They needed to be decreased by one with WYSNC's padded (around or in the top blank); the counters run down in blocks of 64 cycles and the load varied just a bit so it would sometimes overrun; reducing it by one allowed the WYSNC spacer to resolve this as the extra 14 cycles were enough for the variance in the load. It sounds like your issue is similar.

[+nanochess]

Mr SQL, my problem is that sometimes a sprite is way too much to the right only for one frame and the code for the full line does 77 cycles instead of 76.

 

So it triggers the extra line and from what SpiceWare says, I wouldn't like a jitter picture and worst a freezed picture like Nukey Shay says.

 

I'll try to rewrite the code to position the first sprite before the kernel.

Edited October 31, 2013 by nanochess

[+SpiceWare]

Mr SQL, my problem is that sometimes a sprite is way too much to the right only for one frame and the code for the full line does 77 cycles instead of 76.

 

So it triggers the extra line and from what SpiceWare says, I wouldn't like a jitter picture and worst a freezed picture like Nukey Shay says.

 

I'll try to rewrite the code to position the first sprite before the kernel.

 

 

I suspect that's when a sprite moved left and wrapped from 0 to 255. When moving left use code like this:

if X = 0
  X = 159
else
  X = X - 1  

[+nanochess]

I've the classic positioning routine "SBC #15 BCS" and I've an X coordinate in the range 150-159, so it uses 5 extra cycles while updating various other TIA registers, so by one tiny cycle it wraps to an extra line and gives me 263 lines.

[+nanochess]

Well, just I've confirmed in real hardware that changing from 262 to 263 lines causes a small jittering in screen.

 

I'm working towards to solve it.

 

If anyone wants to see my homebrew board in action, I'm putting a picture

Edited November 1, 2013 by nanochess