Overscan and VBlank line counts

[RevEng]

I'd like to have a kernel with 35 lines of vblank and 32 lines of overscan, instead of the usual 37/30 split. The overall line count would still be 262.

 

Does anybody have any insight if this would cause any compatibility problems? I'd expect not, but I thought I'd fire it out there to see what you guys think.

[Nukey Shay]

Aren't these just guidelines? Therefore...the further you drift from these figures, the greater chance that your display will run into compatability problems for some televisions. There are loads of games that deviate from this "standard" (including Combat, BTW).

[Rybags]

Not a 2600 programmer here, but the critical thing would be 3 VSYNC lines.

 

Second most important would be 262 (NTSC) or 312 scanlines (PAL) although supposedly some games deviate slightly from that.

 

The "displayable visible lines" thing though comes up a lot - it's generally safe to use about 232 lines (PAL), but NTSC probably closer to 216.

 

These days it's a lot less critical though because newer TVs tend to be more "precise" and generally have less overscan area than older ones.

[RevEng]

Aren't these just guidelines? Therefore...the further you drift from these figures, the greater chance that your display will run into compatability problems for some televisions. There are loads of games that deviate from this "standard" (including Combat, BTW).

Agreed.

 

But I'm trying to find the lesser of two demons - is it worse for a program to sometimes to run over overscan time and cause an overall linecount bounce, or to always have 2 less lines of vblank and 2 more overblank lines.

 

If I had to guess, I'd say the latter would be compatible with more TVs in the wild. But its not much more than a hunch that TVs would prefer a stable slightly-off frame.

 

Not a 2600 programmer here, but the critical thing would be 3 VSYNC lines.

 

Second most important would be 262 (NTSC) or 312 scanlines (PAL) although supposedly some games deviate slightly from that....

I'm thinking along those lines too.

Edited October 21, 2010 by RevEng

[Nukey Shay]

But I'm trying to find the lesser of two demons - is it worse for a program to sometimes to run over overscan time and cause an overall linecount bounce, or to always have 2 less lines of vblank and 2 more overblank lines.

 

Oh...if it's a case of an unstable screen vs. something consistent, the latter is better by far Even better is to design the game to conform to the guideline. If this means choosing between 2 routines on seperate frames so that cycle overruns are avoided, so be it.

 

Why do you want to work beyond the guideline? Are you running short on cycle time? Try tweaking the program to use less. This could be as simple as adding lookup tables to get around otherwise-lengthy formulas used in critical areas, giving more resources or priority to often-used routines, adding redundancy to handle condition-specific code so that less time is spent rechecking some aspect...etc.

[RevEng]

It's a cycle issue. But it's someone else's code and it's already filling up 8 4k banks and there's a boatload of conditional logic happening in each frame.

 

Cosmetic changes are painful due to the bank with the main loop being stuffed (fight for a few bytes here and there) and shuffling code to other banks would make the cycle issue worse. Any less-than-cosmetic change would really need to amount to a rewrite.

 

So I seek the path of least resistance.

[eshu]

It's a cycle issue. But it's someone else's code and it's already filling up 8 4k banks and there's a boatload of conditional logic happening in each frame.

 

Cosmetic changes are painful due to the bank with the main loop being stuffed (fight for a few bytes here and there) and shuffling code to other banks would make the cycle issue worse. Any less-than-cosmetic change would really need to amount to a rewrite.

 

So I seek the path of least resistance.

 

I'd suggest finding out what other games which don't conform to the standard are doing - it might be that running it with 37/32, 264 scanlines and a screen refresh just under 60hz is more suitable....

 

EDIT: or what about cutting 2 lines off of the display and hitting your overscan routine sooner?

Edited October 21, 2010 by eshu

[Nukey Shay]

Path of least resistance is to make the game PAL-only. You get loads of cycle time

[+SpiceWare]

No, the times are not set in stone. Minor variations are acceptable. What's not acceptable is if the scan line count various over time (such as 262 for one frame, 263 for the next).

 

For Stella's Stocking we used 264 scan lines instead of 262. For Medieval Mayhem I used 262, but with 200 visible scan lines instead of the usual 192.

[Nukey Shay]

Another trick is to move often-used array variables to temps, then move them back after everything has been dealt with. That way, a program can take advantage of the speedier addressing mode rather than always adjusting indexed variables (which adds 1-4 cycles per operation depending on what instruction is being used). After a few operations have been done to offset the additional time of loading/storing, you begin to save time.

 

If collisions are being checked, try dividing them up over a number of frames rather than checking everything on every frame.

 

Is this a bB program? If so, try to convert lines to inline assembly where you can. A Basic interpreter cannot produce efficient code half as well as a person can.

 

Try to discover the conditions that produce the cycle overrun. Then see if some of that overload can be put someplace else when not much is going on. If you are working in assembly, small tasks can be moved to where you would otherwise use delay loops in a display kernel (where time is often being wasted all over the place).

[RevEng]

Thanks for the suggestions guys!

 

Nukey, that's all good advice. If it was my own code I would have reworked the code and eliminated the cycle overages before I even posted this. But it's not, and I don't see any particularly bad hotspot when I'm looking through the code, so I'd likely have to optimize a big chunk of it. I don't relish all that rework.

 

Thanks for the confirmation SpiceWare. I'm only looking for a small change, so it looks good. I think I'll just aim for 264 lines in the end - if it's good enough for Stella's Stocking, it's good enough for me.

[Omegamatrix]

You can change the number of scanlines in Vblank and Overscan for sure. Actually to tell the truth I often just get my program at 262 lines in Stella and then try it on real hardware. What I'm looking for on real hardware is to see how centered the screen is.

 

 

If you take away lines from overscan and add them to Vblank the result is the screen starts moving downward. So write a few test programs and see how centered the result is on your TV.

[SeaGtGruff]

Just to add to the other replies...

 

I believe the *minimum* line counts for a 262-line display should be

 

3 overscan lines

3 vsync lines

15 vblank lines

 

You can of course draw *more* overscan and vblank lines than that, but not *fewer* than that.

 

This is based on the NTSC signal specifications which give 3 lines of pre-equalizing pulses, 3 lines of vertical sync pulses, and 3 lines of post-equalizing pulses, plus 12 lines of regular vertical blank. (Some specifications show only 10 lines of regular vertical blank after the post-equalizing pulses, which would go up to only line 19-- where line 1 is counted as the first line of pre-equalizing pulses-- but the closed-captioning is sent on line 21, which implies that you need 12 lines of regular vertical blank after the post-equalizing pulses.)

 

The Atari 2600 doesn't have "equalizing pulse" lines, just regular vblank lines, so use vblank for the 3 pre-equalizing lines or overscan, followed by the 3 vsync lines, and add the 3 post-equalizing lines and 12 regular vertical blank lines together to get 15 vblank lines after vsync. That's a total of 21 blanked lines, which leaves 241 lines for the active signal or picture-- a total of 262 lines.

 

As already noted, your total lines can be slightly more or less than that, but the total lines should stay steady from frame to frame, and the interval between the vsync on one frame and the vsync on the next frame should also be constant.

 

For PAL, you need to be sure the total number of lines is an even number, otherwise the alternating phases of the color signal will cancel out and you'll get shades of gray instead of colors.

 

Aside from the above requirements, there are three things to keep in mind when deciding how many overscan and vblank lines to draw:

 

(1) The more blanked lines you draw above and below the active picture, the better the likelihood that everything in the picture will be visible on most sets. Most TVs deliberately "overscan" the picture, meaning they display a viewable area that's actually smaller than the whole picture, such that part of the picture extends beyond the edges of the screen in all four directions. They do this so none if the blanking will be visible, apparently because in the early days of TV people thought there was something wrong with their set if they could see a black area at one or more of the four edges of the screen. But with video games and computer screens, you want to be sure the entire picture is visible, since you don't want to be typing a document or reading a page and have some of the text or graphics run past the edges of the screen, or have an alien that's "offscreen" shoot you and kill you. Most computer monitors (especially CRT monitors) let you adjust the horizontal and vertical size of the display, and shift the display left/right/up/down, so you can make the picture fit the display area as precisely as possible. But most TV sets don't have that feature, and there can be quite a bit of variation as to how much a particular set overscans the picture, or how much overscanning is done on the four sides of the screen. So video game consoles and home computers that were designed to be viewed on a TV set typically "underscan" the screen, meaning they deliberately draw the picture so it's smaller than the screen. On the Atari 2600 this gives a black border around the game screen, but on some home computers (like the Atari 800) the border can be in color because it's made up of an active signal rather than blanking. You can't do anything about the 2600's horizontal blanking period, so there's always going to be a black border on the left and right, but you can get rid of the black border on the top and bottom by reducing the number of overscan and vblank lines (as long as you don't go below the minimums listed above). But if you do that, the chances are good that part of the game screen will go "offscreen" at the top and bottom of some TV sets.

 

(2) Since different TVs have different amounts of overscanning on the four sides of the screen, your game screen may or may not be vertically centered on the screen. If you decrease the overscan and increase the vblank, or vice versa, you might get a centered picture on *your* TV set, but it might not be centered on other people's TVs. But that doesn't really matter, as long as none of the game screen extends past the top or bottom edge of the screen. I believe the guidelines that are given in the "Stella Programmer's Guide" were developed by Atari to fit the "worst case scenarios" of older TVs that have a lot of overscanning. I think most modern TVs have less overscanning, but if you're creating a game for sale, you still want to try to design it for a "worst case scenario," since you can't be sure that everyone who buys your game will have a modern TV that has very little overscanning.

 

(3) Remember that most of your game processing logic will be performed during the vertical blanking period, either during the overscan, the vblank, or both. If you reduce the length of the overscan and/or vblank, you'll have fewer cycles for doing your game processing routines. And if you're performing certain routines during the overscan, and other routines during the vblank, you'll want to be sure you leave yourself enough time during each for all the things you're needing to do-- unless you design your kernel in such a way that the tasks are spread out over multiple frames, instead of doing all of the tasks during each frame.

 

Michael

 

 

 

[RevEng]

Thanks for the confirmation, OmegaMatrix and Michael!

 

I've gone ahead and moved the visible display to give overscan 2 more lines of time, and the cycle issue is gone. I'll give it a test on real hardware, but I doubt 2 lines is going to hide any graphics, even on older more-clipping TVs.

[Octavio Pinho Bokel]

I am sorry to bring back a this topic but I still have 2 questions.

 

1 - Why I don't have to draw the exact lines especification of the NTCS signal, how the television is ok with that?

 

"What's not acceptable is if the scan line count various over time (such as 262 for one frame, 263 for the next)" - SpiceWhare

2 - What happens if I send a variable number of lines each frame? It is working ok on Stella emulator... (My game is becoming complex and sometimes the logic to draw a line can go over the expected time if some very RARE conditions are met) In the emulator I see a little distortion that almost never happen and I now that the code outputted one more line to the TV. What would happen on I real TV. (I still don't have the real piece of hardware....)

 

 

3 - (You Don't have to answer that one) - I used my full name stead of a user name (distraction/stupidity). And I can't find any where to change it. Is it possible?

[Rybags]

1 - there's a certain amount of leeway with CRTs. Scanning is generated by sawtooth generators which partly control the beam position. So long as the sync pulses occur within certain time limit vs what's expected then it should be OK.

LCDs with modern tuners a little different but usually there is decent tolerance for out of spec signals.

 

2 - variable lines per frame, not a good idea. Results could vary among TVs, anything from picture annoyingly jumping about to rolling might be the result. Also, with PAL there's the potential to throw the swinging colourburst away from what's expected which can result in wrong colours.

For something like a title screen vs game screen having a couple scanlines difference, probably doesn't matter but really what reason would you need to do things like that?

 

3 - don't know. 1 post, you may as well just delete the account and start another user name. This thread won't be deleted, probably the username field goes blank though.

[Octavio Pinho Bokel]

Thanks!

 

I am representing a highway with 8 car lines (I will implement asymmetry soon, now is just four lines) Cars have different sizes. I have the vertical resolution of 64 lines (update the tia every 3 lines) so I can represent the highway state with 64 bytes, one bit per car line, one means that I should paint the car in that line. So, if I have to draw the car in every line, I have a overtimeme... but is rare. The car occupies 3 bits of the playfield. I will have to rewrite my code, since you said that can happen a lot of bad things and I believe you

 

The code that update one playfield value:

 

LDA #$0 ;Clear cache

STA PF1Cache

DrawCar0

LDX TrafficOffset0

LDA TrafficCacheStart,X

AND #%10000000

BEQ SkipCar0Draw

LDA #%01110000

STA PF1Cache

SkipCar0Draw

DrawCar1

LDX TrafficOffset1

LDA TrafficCacheStart,X

AND #%01000000

BEQ SkipCar1Draw

LDA PF1Cache

ORA #%00000111

STA PF1Cache

SkipCar1Draw

PS: I could make my repository public while developing this game. Is it what most people do here?

[+SpiceWare]

1 - Why I don't have to draw the exact lines especification of the NTCS signal, how the television is ok with that?

The specs for NTSC includes a lot of tolerance due to limitations of the technology at the time. Read up on Overscan and Safe Area, those should help you understand more about why line specifications like 37 for Vertical Blank and 30 for Overscan can be changed.

 

Modern TVs often expect a near perfect signal - my HDTV won't work with my Atari 2600, 7800 or Sega Nomad (haven't tried my Coleco yet). If you search these forums you'll find a number of posts about "my classic system won't work with my HDTV/LCD/flat panel/etc".

 

 

2 - What happens if I send a variable number of lines each frame? It is working ok on Stella emulator... (My game is becoming complex and sometimes the logic to draw a line can go over the expected time if some very RARE conditions are met) In the emulator I see a little distortion that almost never happen and I now that the code outputted one more line to the TV. What would happen on I real TV. (I still don't have the real piece of hardware....)

 

As awesome as Stella is, and homebrew development would be seriously set back without it, it's not the real thing. Things that cause jitter/roll on real equipment may or may not cause a visible problem in Stella. Basically if Vertical Blank takes too long you'll see the image in Stella shift downward for that frame then jump up for the next frame(assuming run-time is correct for that one). The shifting image is known as jitter. If Overscan takes too long, you won't see anything. You can, however, tell Stella to stop execution if you exceed the count. Random Terrain wrote up a nice post about this.

 

Stella also doesn't handle all known TIA tricks. An example of that would be the recently figured out 32 character text display. On real equipment you'll see this:

 

On Stella you'll see some extra stuff to the left:

 

Stella will eventually show this correctly, just need to figure out how/why that trick works so it can be correctly emulated.

Edited March 5, 2014 by SpiceWare

[+SpiceWare]

 

PS: I could make my repository public while developing this game. Is it what most people do here?

 

 

 

You'll get much better help if people can see your code.

[Octavio Pinho Bokel]

Thanks a lot, it was not just a answer. It was almost a Article!

 

You guys rules!

 

I am still thinking about punting the repository public, a I am afraid of someone steeling the code and publishing the game before me...

[eshu]

The code that update one playfield value:

 

LDA #$0 ;Clear cache

STA PF1Cache

 

DrawCar0

LDX TrafficOffset0

LDA TrafficCacheStart,X

AND #%10000000

BEQ SkipCar0Draw

LDA #%01110000

STA PF1Cache

SkipCar0Draw

 

DrawCar1

LDX TrafficOffset1

LDA TrafficCacheStart,X

AND #%01000000

BEQ SkipCar1Draw

LDA PF1Cache

ORA #%00000111

STA PF1Cache

SkipCar1Draw

Uses Y, but should do the same and save 10 cycles off the worst case scenario:

LDY #%00000000 ;Clear cache
 
DrawCar0
 LDX TrafficOffset0
 LDA TrafficCacheStart,X
 BPL SkipCar0Draw
 LDY #%01110000
SkipCar0Draw
 
DrawCar1
 LDX TrafficOffset1
 LDA TrafficCacheStart,X
 AND #%01000000
 BEQ SkipCar1Draw
 TYA
 ORA #%00000111
 TAY
SkipCar1Draw
 STY PF1Cache

Edited March 5, 2014 by eshu

[Octavio Pinho Bokel]

Good,

 

I loved the BPL SkipCar0Draw since it will be a negative number if the first car is on

But for the rest of the cars it will not gain a lot of performance (8 car lines) and I have the ovehead of saving the Y register, since he is my current line, and restoring it

 

I manage to make it run constant at 262. (alt + l) and a lot of things will change in the code, since will be a asymmetrical playfield, if nedded I will apply your solution.

 

Is there any way of making my code public only for the people registered at atari age?

 

Thanks

[eshu]

Guessing at the rest of your code it would be 8 cycles saved for each other pair of cars, and take 6 cycles to save and restore Y so 10+8+8+8-6=28 cycles saved, could be enough to bring you back to 262 lines....

[Omegamatrix]

 

Uses Y, but should do the same and save 10 cycles off the worst case scenario:

LDY #%00000000 ;Clear cache
 
DrawCar0
 LDX TrafficOffset0
 LDA TrafficCacheStart,X
 BPL SkipCar0Draw
 LDY #%01110000
SkipCar0Draw
 
DrawCar1
 LDX TrafficOffset1
 LDA TrafficCacheStart,X
 AND #%01000000
 BEQ SkipCar1Draw
 TYA
 ORA #%00000111
 TAY
SkipCar1Draw
 STY PF1Cache

 

 

You could also do something like this, and spare Y.

  ldx TrafficOffset1        ;3
  lda TrafficCacheStart,X   ;4
  sta PF1Cache              ;3
  bit PF1Cache              ;3  tested now, and used with BVC later. PF1Cache gets updated at the end of routine...

  ldx TrafficOffset0        ;3
  lda TrafficCacheStart,X   ;4
  and #%10000000            ;2

  bpl SkipCar0Draw          ;2³  branch, if A=0
  eor #%11110000            ;2   bit 7 gets flipped, and A=%01110000
SkipCar0Draw:
  bvc SkipCar1Draw          ;2³
  ora #%00000111            ;2
SkipCar1Draw:
  sta PF1Cache              ;3

[eshu]

I knew there'd be a trick with BIT, but I couldn't see it - ok a little bit of extra rom used, but how about:

	LDX TrafficOffset0		
	LDA TrafficCacheStart,X		
	BPL NoCar0			
	LDX TrafficOffset1
	LDA TrafficCacheStart,X
	AND #%01000000
	BEQ Car0NoCar1
	LDA #%01110111
	BNE StoreCache
Car0NoCar1
	LDA #%01110000
	BNE StoreCache
NoCar0
	LDX TrafficOffset1		
	LDA TrafficCacheStart,X	
	AND #%01000000		
	BEQ StoreCache	
	LDA #%00000111	
StoreCache	
	STA PF1Cache	

I make that 29 cycles in the worst case.....

Edited March 6, 2014 by eshu