A2600 Video Display Question

[BigD73]

Ok, I have had an Atari 2600 since 79' but I have always had a question. What are the several Horizontal lines that run down the left side of the screen? They are black and look like the picture is off center but it is not. Currently I have 4 A2600 of different styles and they all have the same thing. Thanks in advance.

[Lord Thag]

That's kind of like asking a physics major 'what those subatomic particles are all about'.

 

The short version has to do with timing and the way the 2600 repositions sprites horizontally. 2600 programming is very hard to explain if you don't know anything about it. It's a fun subject, but it's very hard. Try reading up over on one of the programming forums.

[Robert M]

What you are seeing is sometimes called the comb or comb effect. It is produced by the video chip in the 2600 called the TIA on every scanline where the software has requested the TIA to horizontally reposition an object on the screen using the HMOVE feature of the TIA. Activision eliminated the comb, by requiring all games to hit HMOVE every scanline thereby producing a solid black band on the left edge which makes the game image appear off center.

 

Many people consider the comb to be a bug, because it can look ugly. I wonder if the designers might have put the comb in on purpose as a means to scroll sprites off and on the edges of the screen. Without the comb, a sprite off one edge will appear sticking out on the other side unless you do some nifty tricks in software. the comb is the same width as a standard sprite (8 pixels). So a programmer can use the comb as a sort of virtual backstage curtain to move sprites in and out as if entering or leaving a stage.

 

Cheers!

Edited June 27, 2005 by Robert M

[danwinslow]

ow brane hert

[BigD73]

Thanks alot for the information. I have always been curious why the lines appeared but you cleared that up for me. Thanks Again.

[supercat]

Many people consider the comb to be a bug, because it can look ugly.  I wonder if the designers might have put the comb in on purpose as a means to scroll sprites off and on the edges of the screen.  Without the comb, a sprite off one edge will appear sticking out on the other side unless you do some nifty tricks in software.  the comb is the same width as a standard sprite (8 pixels).  So a programmer can use the comb as a sort of virtual backstage curtain to move sprites in and out as if entering or leaving a stage. 

881844[/snapback]

 

Unlike most video chips which uses a position register for each sprite and have logic to check when the beam reaches the specified position, the 2600 uses a different scheme (which possibly saves a few transistors, though given some of the weird stuff they added to deal with it I don't know how much it really saves).

 

Each sprite on the 2600 has a counting circuit which will trip every 160 pulses. Normally there are 160 pixels on a scan line, and so the counter will trip at the same location every scan line. This would be all well and good if all you wanted to do was display a sprite at whatever position it powered up at and never wanted to move it. In practice, though, being able to move sprites is nice (well, actually pretty much essential for making any sort of playable game). There are two ways to move the player sprites and the ball, and three ways to move the missiles.

 

The first way to move any of these objects is to write to a special location, called the object's "reset address", which will cause the object's counter to be zeroed. This will cause the object to appear on every scan line at whatever X coordinate the electron beam happens to be. It is fairly easy to position objects to within +/- 7 pixels of any desired position (a 15-pixel range) by executing a variable delay loop before hitting the object's reset address. With trickier code, accuracy can be refined to +/- 1 (a three-pixel range). Placement more precise than this is not possible when using the reset address alone.

 

Because the designers of the Atari figured people would want more precise object placement than would be allowed using just the reset addresses, they added a ludicrously complicated bunch of circuitry which may be called the "hmove circuit". The HMOVE circuitry does two things:

 

-1- It feeds sprites' position counters an extra 0-15 counts during the horizontal blanking period. In the absense of part 2, this would have the effect of moving the sprites 0-15 pixels to the right.

 

-2- It disables counting (and video) for the first eight pixels of a scan line. This has the effect of moving all five sprites eight pixels to the right (offset by whatever amount they were moved in -1-).

 

There are many other weird and wacky intricacies with the TIA, and it must have had a somewhat interesting evolution (I don't think counting to 160 is really any easier than counting to 168, and if the counters did the latter there'd be no need to blank the first part of a display line when performing an HMOVE.

 

BTW, method #3 for moving missles is to program the hardware to trigger a reset of the a missle position counter when its corresponding player sprite has just output its fourth pixel of display data. Combad uses this when the player fires, but I really don't know of much other usefulness for this feature. Seems a waste of silicon that could have been better used elsewhere.

[carmel_andrews]

Many people consider the comb to be a bug, because it can look ugly.  I wonder if the designers might have put the comb in on purpose as a means to scroll sprites off and on the edges of the screen.  Without the comb, a sprite off one edge will appear sticking out on the other side unless you do some nifty tricks in software.  the comb is the same width as a standard sprite (8 pixels).  So a programmer can use the comb as a sort of virtual backstage curtain to move sprites in and out as if entering or leaving a stage.  

881844[/snapback]

 

Unlike most video chips which uses a position register for each sprite and have logic to check when the beam reaches the specified position, the 2600 uses a different scheme (which possibly saves a few transistors, though given some of the weird stuff they added to deal with it I don't know how much it really saves).

 

Each sprite on the 2600 has a counting circuit which will trip every 160 pulses. Normally there are 160 pixels on a scan line, and so the counter will trip at the same location every scan line. This would be all well and good if all you wanted to do was display a sprite at whatever position it powered up at and never wanted to move it. In practice, though, being able to move sprites is nice (well, actually pretty much essential for making any sort of playable game). There are two ways to move the player sprites and the ball, and three ways to move the missiles.

 

The first way to move any of these objects is to write to a special location, called the object's "reset address", which will cause the object's counter to be zeroed. This will cause the object to appear on every scan line at whatever X coordinate the electron beam happens to be. It is fairly easy to position objects to within +/- 7 pixels of any desired position (a 15-pixel range) by executing a variable delay loop before hitting the object's reset address. With trickier code, accuracy can be refined to +/- 1 (a three-pixel range). Placement more precise than this is not possible when using the reset address alone.

 

Because the designers of the Atari figured people would want more precise object placement than would be allowed using just the reset addresses, they added a ludicrously complicated bunch of circuitry which may be called the "hmove circuit". The HMOVE circuitry does two things:

 

-1- It feeds sprites' position counters an extra 0-15 counts during the horizontal blanking period. In the absense of part 2, this would have the effect of moving the sprites 0-15 pixels to the right.

 

-2- It disables counting (and video) for the first eight pixels of a scan line. This has the effect of moving all five sprites eight pixels to the right (offset by whatever amount they were moved in -1-).

 

There are many other weird and wacky intricacies with the TIA, and it must have had a somewhat interesting evolution (I don't think counting to 160 is really any easier than counting to 168, and if the counters did the latter there'd be no need to blank the first part of a display line when performing an HMOVE.

 

BTW, method #3 for moving missles is to program the hardware to trigger a reset of the a missle position counter when its corresponding player sprite has just output its fourth pixel of display data. Combad uses this when the player fires, but I really don't know of much other usefulness for this feature. Seems a waste of silicon that could have been better used elsewhere.

882005[/snapback]

 

__________________________________________________________________

 

 

Are u sure you didn't eat the TIA/2600 programming manual at birth

 

Or do you just eat video chips

[+batari]

-1- It feeds sprites' position counters an extra 0-15 counts during the horizontal blanking period.  In the absense of part 2, this would have the effect of moving the sprites 0-15 pixels to the right.

 

-2- It disables counting (and video) for the first eight pixels of a scan line.  This has the effect of moving all five sprites eight pixels to the right (offset by whatever amount they were moved in -1-).

882005[/snapback]

I have read that you can move sprites and avoid the black lines by calling HMOVE 2 cycles early, but the effect is that it moves 0-15 pixels instead of -7 to 8. I imagine this has something to do with the above

[supercat]

I have read that you can move sprites and avoid the black lines by calling HMOVE 2 cycles early, but the effect is that it moves 0-15 pixels instead of -7 to 8.  I imagine this has something to do with the above

882203[/snapback]

 

It would most certainly have a lot to do with the above. I'll have to play around with that, since being able to move eight pixels left could be useful.

[Robert M]

-1- It feeds sprites' position counters an extra 0-15 counts during the horizontal blanking period.  In the absense of part 2, this would have the effect of moving the sprites 0-15 pixels to the right.

 

-2- It disables counting (and video) for the first eight pixels of a scan line.  This has the effect of moving all five sprites eight pixels to the right (offset by whatever amount they were moved in -1-).

882005[/snapback]

I have read that you can move sprites and avoid the black lines by calling HMOVE 2 cycles early, but the effect is that it moves 0-15 pixels instead of -7 to 8. I imagine this has something to do with the above

882203[/snapback]

 

 

That is true. There is a very well done analysis on the Stella mailing list. I can't find it right now. The author hit the HMOVE function on each clock cycle and measured what happened for all possible movement values. IIRC hitting HMOVE on cycle 74 or 75 will move the object from 0 to 15 pixels to the right from its current position without drawing the comb. So with some planning you can get rid of the comb. The biggest trick would be placing a sprite on the left most side of the screen. Doing so becomes a special case if you can't HMOVE to the left. You would have to rough position on the right side and shift off the right side onto the left.

 

There is another HMOVE trick that was first used in Cosmic Ark and I believe again in Rabbit Transit. The star field in Cosmic Ark is made by hitting HMOVE normally at the start of the first line, then writting one of a few special values to the target object's HMxx register on cycle 18 (IIRC). The result is the HMOVE function gets stuck turned on, and the object moves 15 pixels to the left (I think) every scanline until HMOVE is hit again. That is how the star field is generated in Cosmic Ark. Its the ball object smeared over the whole screen with an color wave on top to make it extra nice.

 

Cheers!

[Cybergoth]

Hi there!

 

That is true.  There is a very well done analysis on the Stella mailing list.  I can't find it right now.

 

It's rather old news: http://www.biglist.com/lists/stella/archiv...4/msg00198.html

 

For example Gunfight does that when repositioning the cowboys after the state display.

 

Greetings,

Manuel

[ehenciak]

Because the designers of the Atari figured people would want more precise object placement than would be allowed using just the reset addresses, they added a ludicrously complicated bunch of circuitry which may be called the "hmove circuit".  The HMOVE circuitry does two things:

 

Actually, the circuit is quite simple! All you do is load a counter and set a latch (early HBLANK). There are one of these for each of the 5 objects. To the programmer this is nutsy, but the hardware solution is rather simple. If you look at the TIA schematics, it is created with a bunch of circuits that are used elsewhere....you'd lay these out once and reuse much like you'd do today.

 

Basically, if the counter is not done counting, a clock pulse derived from the main 3.579545MHz clock is gated to the object.

 

Now, if you load this counter on the cycle it is supposed to clear, it actually never clears. Therefore, on virtually every cycle (still confirming this), the object counter is advanced thus creating the starfield effect in Cosmic Ark!

 

 

There are many other weird and wacky intricacies with the TIA, and it must have had a somewhat interesting evolution (I don't think counting to 160 is really any easier than counting to 168, and if the counters did the latter there'd be no need to blank the first part of a display line when performing an HMOVE.

 

Keep in mind that TIA only counts to 40. There are 160 ticks of the "main oscillator" during the drawing time. However, each object gets this main oscillator divided by four. To count to 40 with a minimal number of gates, a simple LFSR counter is used as well as associated decoding circuitry (a wired AND structure). And, to get the job done faster, this LFSR is used throughout TIA (again, design once and reuse). To do a binary counter and count to 160 (or 40 for that matter), you'd need more gates. The player pixel counter is a binary counter and is larger than the LFSR counter in terms of gates.

 

Another thing, you'd need an 8-bit binary counter to count to 160/8 and I would suspect that you'd need J-K flops as opposed to the nice latches TIA uses in the LFSRs. This increases area big time...

 

 

BTW, method #3 for moving missles is to program the hardware to trigger a reset of the a missle position counter when its corresponding player sprite has just output its fourth pixel of display data.  Combad uses this when the player fires, but I really don't know of much other usefulness for this feature.  Seems a waste of silicon that could have been better used elsewhere.

 

This is a total guess, but I would suspect Gunslinger, Air-Sea Battle, etc. used this feature. It required virtually no silicon to implement and allows the programmer to turn a bit on and have the player object control it's corresponding missile while the player is moving. Therefore, I would suspect sofware wouldn't have to do any housekeeping of a missile object until it is fired. Again, that is a hunch...I do not know that for certain.

 

What pissed me off were the vertical delay registers...their "chaining" caught me off guard...you should see some games look like when you do not properly emulate this in hardware (or software for that matter).

 

Oh well, sorry for the rambling...

 

Ed

[+batari]

What pissed me off were the vertical delay registers...their "chaining" caught me off guard...you should see some games look like when you do not properly emulate this in hardware (or software for that matter).

882379[/snapback]

I wonder if this is why the cobra in GI Joe is screwy even in the newest versions of Stella? I always wondered about that cobra - it looks like there's a lot of funny tricks involved.

[supercat]

Actually, the circuit is quite simple!  All you do is load a counter and set a latch (early HBLANK).  There are one of these for each of the 5 objects.  To the programmer this is nutsy, but the hardware solution is rather simple.  If you look at the TIA schematics, it is created with a bunch of circuits that are used elsewhere....you'd lay these out once and reuse much like you'd do today.

 

It would seem that the TIA uses a four-bit counter and five 4-bit comparators to handle the HMOVE circuit, in addition to having to have the five divide-by-160 units and the sequencing logic for the HMOVE. Doesn't that seem a little overcomplicated to you?

 

Perhaps there's something in the hardware that makes it simpler than it sounds, but some of the quirks suggest that they did not use any of the simplifying approaches I can think of.

 

Now, if you load this counter on the cycle it is supposed to clear, it actually never clears.  Therefore, on virtually every cycle (still confirming this), the object counter is advanced thus creating the starfield effect in Cosmic Ark!

I find this puzzling, actually. I would think the simplest way to handle the hardware would be to have four derived signals during hblank which pulse (non-overlapping), one, two, four, and eight times. Just AND these signals with the appropriate bits in the HMxxx register and use that to add clocks.

 

Keep in mind that TIA only counts to 40.  There are 160 ticks of the "main oscillator"  during the drawing time.  However, each object gets this main oscillator divided by four.  To count to 40 with a minimal number of gates, a simple LFSR counter is used as well as associated decoding circuitry (a wired AND structure).  And, to get the job done faster, this LFSR is used throughout TIA (again, design once and reuse).  To do a binary counter and count to 160 (or 40 for that matter), you'd need more gates.  The player pixel counter is a binary counter and is larger than the LFSR counter in terms of gates.

 

When I said "count" to 160/168, I didn't necessarily mean using a binary ripple counter; I meant simply have a circuit which produces one output pulse every 160 or 168 input pulses. While the counter circuitry used to generate scan lines may divide by four and then divide by 57, the sprite circuits clearly divide by 160, since it takes 160 pulses to move them an entire line.

 

BTW, method #3 for moving missles is to program the hardware to trigger a reset of the a missle position counter when its corresponding player sprite has just output its fourth pixel of display data.  Combad uses this when the player fires, but I really don't know of much other usefulness for this feature.  Seems a waste of silicon that could have been better used elsewhere.

 

This is a total guess, but I would suspect Gunslinger, Air-Sea Battle, etc. used this feature. It required virtually no silicon to implement and allows the programmer to turn a bit on and have the player object control it's corresponding missile while the player is moving. Therefore, I would suspect sofware wouldn't have to do any housekeeping of a missile object until it is fired. Again, that is a hunch...I do not know that for certain.

 

Air Sea battle might possibly use it, though there's really no point since the player's gun is always in the same spot. Most other games care about the shot X position, and would thus have no problem manipulating it directly.

 

What pissed me off were the vertical delay registers...their "chaining" caught me off guard...you should see some games look like when you do not properly emulate this in hardware (or software for that matter).

 

The delay registers are necessary for many useful effects, though the term "vertical" is a misnomer. I find it interesting that the function is implemented using a mux instead of simply forcing the second register to act as a transparent latch when the delay is disabled.

 

Oh well, sorry for the rambling...

882379[/snapback]

 

Eh, rambling is fun. BTW, my biggest wish-list item on the 2600 would probably be a circuit which would generate four pulses per scan line and allow the user to have one, two, three, or all four routed to the sound circuitry. Would greatly improve the 2600's otherwise-attrotious intonation.

[ehenciak]

It would seem that the TIA uses a four-bit counter and five 4-bit comparators to handle the HMOVE circuit, in addition to having to have the five divide-by-160 units and the sequencing logic for the HMOVE.  Doesn't that seem a little overcomplicated to you?

 

Yes, this is exactly right. I guess I am referring to the transistor level implementation...it's quite simple...basically (if memory serves) there are two n-channel transistors per bit. One is driven by the "counter" and the other by the value latched in HMOVE. These are all wired in parallel. If any "set" of transistors are not turned on (thus indicating a compare), the line indicating a match is pulled down (i.e. "not" match signal) Therefore, the comparison is quite simple to implement and requires very little in terms of gates..

 

 

Perhaps there's something in the hardware that makes it simpler than it sounds, but some of the quirks suggest that they did not use any of the simplifying approaches I can think of.

Again, I think "known working" far outweighed elegance in TIA.  If you have one known working circuit as well as the associated layout for that circuit, plugging that into your design is the way to go.  No need for verification or anything.  Rule #1 of ASIC design....avoid respins at all costs !  Simply use the LFSR circuits all over the place and be done with it!

 

 

I find this puzzling, actually.  I would think the simplest way to handle the hardware would be to have four derived signals during hblank which pulse (non-overlapping), one, two, four, and eight times.  Just AND these signals with the appropriate bits in the HMxxx register and use that to add clocks.

 

Hmmmm...I think I see what you mean here. The *only* thing I suspect is signal routing might become an issue since this would also be tapped off of what I call the "master sequencer"...these ancient processes only had two metal layers (and perhaps polysilicon) available for routing. So, yes, you could share a lot of circuitry, but for routing purposes, you might have been better off simply slapping down an existing layout and be done with it ! Again, this is all speculation. I have never seen TIA layed out. Now that I have access to a probe station again, I might dig into this some ! I'd like to actually see what TIA looks like !

 

 

Air Sea battle might possibly use it, though there's really no point since the player's gun is always in the same spot.  Most other games care about the shot X position, and would thus have no problem manipulating it directly.

 

Wasn't there a variation where players moved all over the place? I forget....it has been a while ! At any rate, all the early two player games where the point was killing one another probably used this missile to player reset. The more I think about it, the more I agree with you that it is rather useless in the longrun overall.

 

 

The delay registers are necessary for many useful effects, though the term "vertical" is a misnomer.  I find it interesting that the function is implemented using a mux instead of simply forcing the second register to act as a transparent latch when the delay is disabled.

 

Understood on the effects...it is a very irritating bug I created when putting the 2600 onto an FPGA though ! I had printed out the schematics on 8x11" paper...couldn't see that these guys were criss-crossed in how they were chained. I wired player one old to player one and player two old to player two. This causes very interesting problems ! It was perhaps the nastiest problem I made for myself since I had looked at the friggin schematics again and again and never noticed the criss crossing! It was a happy morning (4AM) when I fixed it and played pitfall for an hour or so without a bunch of garbage on the screen !

[supercat]

It would seem that the TIA uses a four-bit counter and five 4-bit comparators to handle the HMOVE circuit, in addition to having to have the five divide-by-160 units and the sequencing logic for the HMOVE.  Doesn't that seem a little overcomplicated to you?

 

Yes, this is exactly right. I guess I am referring to the transistor level implementation...it's quite simple...basically (if memory serves) there are two n-channel transistors per bit. One is driven by the "counter" and the other by the value latched in HMOVE. These are all wired in parallel. If any "set" of transistors are not turned on (thus indicating a compare), the line indicating a match is pulled down (i.e. "not" match signal) Therefore, the comparison is quite simple to implement and requires very little in terms of gates..

 

So why would using an 8-bit binary counter and 8-bit comparator have been a problem? I know an 8-bit counter is more complicated than the linear feedback shift register, but only one counter would have been needed for all the sprites. I guess maybe for sprite cloning the LFSRs work out well, but splitting a comparitor into a most-significant and least-significant part might have worked well.

 

Hmmmm...I think I see what you mean here.  The *only* thing I suspect is signal routing might become an issue since this would also be tapped off of what I call the "master sequencer"...these ancient processes only had two metal layers (and perhaps polysilicon) available for routing.  So, yes, you could share a lot of circuitry, but for routing purposes, you might have been better off simply slapping down an existing layout and be done with it !  Again, this is all speculation.  I have never seen TIA layed out.  Now that I have access to a probe station again, I might dig into this some !  I'd like to actually see what TIA looks like !

 

Heh. Maybe it's that way 'cos I didn't design it. Though I'd have probably made some other different mistakes.

 

BTW, the generation of several non-overlapping timing signals with different power-of-two rates and selective AND'ing of them is really a very nice approach that I'm surprised isn't used more often. If used in baud-rate generators, for examine, it would allow much finer control of baud rates than is otherwise available and yet cost less silicon than existing BRG designs.

 

Wasn't there a variation where players moved all over the place?  I forget....it has been a while !  At any rate, all the early two player games where the point was killing one another probably used this missile to player reset.  The more I think about it, the more I agree with you that it is rather useless in the longrun overall.

 

It's basically only really useful in games where a player is moved around the screen with the program having no clue where it is. In the absense of RESMPx, the program would have to keep track of the player's X position and be able to put the missle there. So for a game like Combat it probably saves four bytes of RAM and 40 bytes of code. Yippie.

 

I had printed out the schematics on 8x11" paper...couldn't see that these guys were criss-crossed in how they were chained.

883317[/snapback]

 

That could cause some interesting problems I'll bet.

 

Sometime I hope to download and examine the Stella schematics; I'm sure they're fascinating. Things like playfield generation and reversal seem interesting. My own inclination with a playfield might have been to have a 48-bit register with write addresses for left half only, right half only normal, both halves with right half normal, and both halves with right half reversed. But that's just me.