Horizontal Positioning is killing me!

[Thomas Jentzsch]

On some other units, however, color 0 is actually lighter than the black generated by VBLANK. This may cause sync problems if VBLANK is not turned on before VSYNC, and may cause funny diagonal stripes lines on some televisions if VBLANK is turned off too soon.

I once made a mistake and didn't turn on VBLANK. The screen rolled on some TVs.

[SeaGtGruff]

Michael I'm sorry, but what you write doesn't seem too helpful.

 

First I would advise to use the proper names of things. Those phases of a TV frame are called "VBLANK Period" and "Overscan Area" or similar. Inventing your own vocabulary doesn't help anyone, especially not when publically advising beginners, who should learn the proper terms.

I didn't make up those terms; they're proper terms in connection with a TV signal-- whereas if you want to be technically correct, the terms "VBLANK period" and "overscan area" are being used improperly by Atari programmers.

 

Properly speaking, the "VBLANK period" is the *full* period during which the three beams (of a color CRT) or single beam (of a monochrome CRT) are set to the blanking level, so it begins at the end of the active area, and extends through the vertical sync, up to the beginning of the active area of the next field.

 

The "overscan area" is properly the portion of the active signal that falls beyond the visible boundaries of the screen, on all four sides. An "overscanned" image is one that's drawn too large to fit on the visible screen (usually deliberately), whereas an "underscanned" image is one that's drawn too small to fill up the entire visible screen. Historically speaking, TV pictures were deliberately overscanned in all four directions so there would be no chance of any blanking showing up at the edges of the screen, whereas computer monitors are often adjusted to underscan the picture to ensure that none of the active display (especially text) extends "offscreen."

 

The correct *TV* terminology for what Atari programmers call "the VBLANK period" is "the vertical back porch." And the correct term for what Atari programmers call "the overscan area" is "the vertical front porch." Googling these terms that you think I made up will show you what I mean. I've spent quite a bit of time during the last half-dozen years reading on the internet about TV signals-- and I'm definitely *not* an expert on TV technology, so I gave myself many headaches trying to absorb everything, and some of the terms sounded funny to me, too. ("Front porch"? "Back porch"? Ooookayyy!) What can I say? The people who designed TV signals are engineers, and engineers like to coin funny terms!

 

The terms "front porch" and "back porch" really apply to the blanking that occurs just before (front porch) or after (back porch) the vertical *or* horizontal sync.

 

The "vertical front porch" is the vertical blanking that occurs before the vertical sync, and the "vertical back porch" is the vertical blanking that continues after the vertical sync. Thus, the "vertical blanking interval" is divided into the vertical front porch, vertical sync, and vertical back porch.

 

Likewise, the "horizontal front porch" is the horizontal blanking that occurs before the horizontal sync, and the "horizontal back porch" is the horizontal blanking that continues after the horizontal sync-- except the horizontal back porch for a color TV signal also contains the colorburst, and the blanking that separates the horizontal sync from the colorburst is referred to as the "breezeway," so the term "horizontal back porch" also seems to be used to describe just the blanking that comes *after* the colorburst, rather than (or in addition to?) the entire blanked portion that follows the horizontal sync.

 

Second, those magic numbers you give may or may not work, but 240 picture lines sound pretty extreme, considering that normal games use 192 or 200 lines. I'm sure it is possible and probably works on your TV, but I wouldn't recommend doing that.

I was describing a non-interlaced *TV* picture signal with 262 lines-- although, looking back, I see that I left out "TV." Many descriptions of a 262.5-line TV signal say there's 242.5 active lines, with 20 blanked lines, but the 21st line (with the closed-captioning data) is also blanked, so it *should* be 241.5 active and 21 blanked lines. Also, it's common to drop the active lines down to 240 per field, giving 480 active lines per frame (i.e., "480i"), rather than the oft-mentioned 483 or 485 active lines per frame.

 

The 21 lines of traditional vertical blanking are divided into pre-equalizing pulses, the sync pulse, post-equalizing pulses, and then several more lines of "normal but blanked" signal. The pre-equalizing and post-equalizing pulses occur at half-line intervals, but if we count them in terms of whole lines, there are 3 pre-equalizing lines, 3 sync lines, and 3 post-equalizing lines (more or less-- some specs seem to show 2.5 post-equalizing lines, whereas others seem to show 3.5 lines). So if we drop the extra half-line per field to get a 262-line non-interlaced frame, and further drop the number of active lines from 241 down to 240, we could put the extra blank line either before the 3 pre-equalizing lines, or after the 12 blank lines that follow the 3 post-equalizing lines-- i.e., either 4-3-15, or 3-3-16, where the three numbers represent the line counts in the front porch, sync, and back porch of the vertical blanking interval. I like to use the former numbers, but I don't know which set of numbers would be considered "correct."

 

For an NTSC Atari game screen, the standard practice is to use about 192 active lines, as you mentioned. So that means we increase the number of lines in the vertical front porch (or "overscan area" as Atari programmers like to call it), as well as in the vertical back porch (or "VBLANK period" as Atari programmers like to call it). Since I use the 4-3-15 numbers, and I prefer to keep the active portion of the picture as vertically-centered as possible, I typically add 24 lines each to the front porch and back porch, resulting in 28-3-39-192 (front porch, sync, back porch, active). The "Stella Programmer's Guide" gives slightly different numbers (30-3-37-192), which should presumably put the active display slightly off-center in the vertical direction, but I doubt if anyone ever pulls out a ruler to measure the "top border" and "bottom border," so there's really a great deal of flexibility in the numbers used-- e.g., you could use 35-3-32-192 if you wanted to, or some other set of numbers that add up to (about) 262, depending on how much time you want to allow for your "overscan" and "VBLANK" periods (as Atarians call them), presumably as long as you have at least 3 blank lines before the vertical sync, at least 15 blank lines after the vertical sync, and don't let any significant portions of your active picture extend into the "overscanned" region of the screen (i.e., you could extend the background color into the "overscanned" region, but you wouldn't want to let the score display extend into the "overscanned" region).

 

For a very solid explanation of those things I'd recommend you and Wickey should read Andrews:

Session 7: The TV and our Kernel

Yep, I've read that, along with the "Stella Programmer's Guide" and "TIA-1 Manual"-- all of which are definitely essential reading for Atari 2600 programmers-- plus a lot of online documents about TV signals (many of which contain conflicting or erroneous information, so anyone who wants to "go there" should be forewarned).

 

Third, there's a tried and trusted macro called VERTICAL_SYNC which is doing a perfect vertical syncing sequence. I encourage everyone to use that and not experiment coding their own here.

The macro is nice, but I often like to do stuff during the 3 vertical sync lines-- e.g., sprite positioning, or updating a frame counter, or anything else useful that can be squeezed into that time-- so I generally code my own vertical sync routine. But for general purposes, the macro is undeniably excellent.

 

There isn't much room here for re-inventing the wheel or too much experimentation. I wouldn't be too surprised if that is where the E.T. Book Cart problems came from.

No, the main technical problem with the "E.T. Book Cart" arose because when I started it, I was doing a version that could switch between 262 lines and 312 lines based on the TV TYPE switch setting, and I was using RAM variables to set the timer values for the vertical front porch and vertical back porch. But then I decided that it was better to just have two separate versions, so I changed the RAM variables to constants-- except I forgot to stick a # sign in the LDA instruction that set the timer for the front porch, so it ended up being a zero-page load instead of an immediate load. (However, it worked fine in the original "multi-format" version, because that version was correctly setting the contents of the RAM variable based on the TV TYPE switch setting.) So the problem had nothing to do with the vertical sync routine; it was setting the timer for the front porch that was the problem. I fixed that problem as soon as I discovered it, and sent the corrected ROMs to Al-- but regrettably, several carts made from the bad ROMs were sent out before I caught my error. Mea culpa.

 

I think there are a couple of other "issues" with the "E.T. Book Cart," but they have nothing to do with the vertical sync and the front and back porches. Rather, I'm speaking of the *colors* used, as well as my decision to use flickered text without doing the "Venetian blinds" technique. Due to the high contrast between the light green playfield color and the black text, exacerbated by not using "Venetian blinds" on each frame, the resultant flickering is rather obnoxious when viewed on a regular CRT-type TV set.

 

My decision to *not* use "Venetian blinds" was based on timing considerations, coupled with the way the text data is stored in ROM and then loaded for the display. I created an ASCII character set that includes four special characters-- horizontal tab (for two consecutive spaces), end-of-line (for all spaces for the remainder of the line), vertical tab (for an end of line followed by a blank line to separate paragraphs from each other), and end-of-page (for all blank lines for the remainder of the screen or "page"). This allowed me to compress the text data more efficiently, because there was a *lot* of text data that I was trying to fit in-- but it also meant I had to check for the four control characters and then accomplish the desired action for each, which increased the amount of time needed to load the character data for a row of text. There just wasn't enough time left to HMOVE the sprites left and right between scan lines.

 

Oddly enough, a few months ago I discovered that "E.T. Book Cart" is flicker-free on my 1080p LCD HDTV. Furthermore, the "Venetian blinds" technique, as well as interlacing two colors together, looks worse instead of better-- it's flicker-free, but the alternating lines are thicker and therefore not as tightly packed together. For example, if I want to blend two colors together-- say, yellow and blue-- then the most flicker-free way to do that on a "regular" TV would be to interlace the two colors on each frame, but swap the order of the colors on alternate frames, as follows:

 

frame 1........frame 2
yellow.........blue
blue...........yellow
yellow.........blue
blue...........yellow

When I display that on my 1080p LCD HDTV, I get the following (flicker-free) result:

 

yellow
yellow
blue
blue
yellow
yellow
blue
blue

But if I flicker two solid frames together-- e.g., a solid yellow frame and a solid blue frame-- I get the following result (also flicker-free):

 

yellow
blue
yellow
blue
yellow
blue
yellow
blue

So on my TV set at least, non-interlaced flickering looks better than interlaced flickering. Alas, I can't count on all 1080p HDTVs producing those same results, since (based on what I've been told) it depends on the algorithms used by the TV manufacturers to convert a 262-line signal into a 1080-line picture, or something like that.

 

Michael

[Devin]

Here's a beautifully written algorithm that I found on these boards some time ago. It works absolutely great. Just call it during the vertical blank - or during the kernal. Be warned that this subroutine consumes two scanlines. I'm using a modified version in one of my projects.

 

;---------------------------------------------------------------
; Subroutine: PositionSprite
;
; In  : a = position.
;	   x = sprite (0 = player 0, 1 = player 1, 2 = missile 0, 3 = missile 1, 4 = ball)
;
; Out : None
;---------------------------------------------------------------
PositionSprite
	sta HMCLR
	sec
	sta WSYNC		 ;begin line 1
PositionSpriteLoop
	sbc	#15
	bcs	PositionSpriteLoop ;+4/5	4/ 9.../54

	eor	#7		 ;+2	  6/11.../56
	asl
	asl
	asl
	asl			   ;+8	 14/19.../64

	sta.wx HMP0,X	 ;+5	 19/24.../69
	sta	RESP0,X	;+4	 23/28/33/38/43/48/53/58/63/68/73
	sta	WSYNC	  ;+3	  0			  begin line 2
	sta	HMOVE	  ;+3
	rts			   ;+6	  9

 

So, if you want to put the player 1 in horizontal position 80, you would use it like this:

 

	 LDX   #1
 LDA   #80
 JSR   PositionSprite

[supercat]

Oddly enough, a few months ago I discovered that "E.T. Book Cart" is flicker-free on my 1080p LCD HDTV. Furthermore, the "Venetian blinds" technique, as well as interlacing two colors together, looks worse instead of better-- it's flicker-free, but the alternating lines are thicker and therefore not as tightly packed together. For example, if I want to blend two colors together-- say, yellow and blue-- then the most flicker-free way to do that on a "regular" TV would be to interlace the two colors on each frame, but swap the order of the colors on alternate frames, as follows:

 

Equivalent to using Z26 with the -! switch.

 

Some televisions will regard any signal as interlaced, whether it is or not, drawing half the scan lines on each field. I've tried a few things to try to 'jinx' a projector into showing a non-interlaced display, but without any luck.

 

Going forward, I don't know the best way to handle such things. Maybe have two display kernels, but that's a somewhat crummy option in some ways, both from a code-duplication standpoint and also a functional one.

[Wickeycolumbus]

Here's a beautifully written algorithm that I found on these boards some time ago. It works absolutely great. Just call it during the vertical blank - or during the kernal. Be warned that this subroutine consumes two scanlines. I'm using a modified version in one of my projects.

 

;---------------------------------------------------------------
; Subroutine: PositionSprite
;
; In  : a = position.
;	   x = sprite (0 = player 0, 1 = player 1, 2 = missile 0, 3 = missile 1, 4 = ball)
;
; Out : None
;---------------------------------------------------------------
PositionSprite
	sta HMCLR
	sec
	sta WSYNC		;begin line 1
PositionSpriteLoop
	sbc	#15
	bcs	PositionSpriteLoop;+4/5	4/ 9.../54

	eor	#7		;+2	  6/11.../56
	asl
	asl
	asl
	asl			  ;+8	 14/19.../64

	sta.wx HMP0,X	;+5	 19/24.../69
	sta	RESP0,X;+4	 23/28/33/38/43/48/53/58/63/68/73
	sta	WSYNC	 ;+3	  0			  begin line 2
	sta	HMOVE	 ;+3
	rts			  ;+6	  9

 

So, if you want to put the player 1 in horizontal position 80, you would use it like this:

 

	 LDX   #1
 LDA   #80
 JSR   PositionSprite

 

Thanks a lot for this, I think this is the one I will use in my game, which currently has no horizontal positioning code.

[Devin]

Thanks a lot for this, I think this is the one I will use in my game, which currently has no horizontal positioning code.

 

I forgot to mention that the subroutine does not clear the horizontal move register afterwards.

 

This should be done at least 20 cycles after the subroutine returns - if you plan to use HMOVE outside the subroutine.