Starpath: How did they make the graphics so good?

[Aegis]

Probably a stupid question but...

 

I picked up the excellent 'Stella gets a new brain' CD and I've been playing Frogger using Z26 - the graphics (relatively speaking ;^) are amazing! I know the Supercharger had 6k of RAM but all of the Starpath games seem to have much better graphics than even the 8k carts (excluding possibly Activision who made some graphically stunning games).

 

I'm just scratching my head wondering how on earth they did it - kudos to Starpath's programmers - they were obviously an incredibly talented bunch!

[supercat]

I'm just scratching my head wondering how on earth they did it - kudos to Starpath's programmers - they were obviously an incredibly talented bunch!

 

A major key to getting good graphics out of the Atari 2600 is being able to get data out to the TIA quickly; this means minimizing the amount of time spent figuring out where data should come from. This leads to two types of optimization that can use up RAM very quickly:

• Having a buffer which holds the data that need to be output, in the order they'll be required, padded with zeros as necessary.
  
• Having code which can be modified on the fly as needed.
  

Pre-buffering data can greatly reduce the amount of decision-making that's required during a scan line. For example, suppose a game needs to display an object on a certain range of scan lines, and blank the sprite on the remainder. Using conventional methods would yield code something like:

  txa				; Assumes line counter is in X
 sbc p0_ypos
 cmp #16
 bcc load_it
 lda #0
 clc
 beq rest_of_loop
load_it:
 tay
 lda (ptr),y
rest_of_loop:
 sta GRP0
 ...rest of loop

That takes 19-20 cycles to handle one sprite. If there were a table set up that held the GRP0 data for every scan line (including the blank ones), the code could be greatly reduced:

  lda grp0buff,x ; Assumes line counter is in X
 sta GRP0

That slashes the time from 19-20 cycles down to seven. A huge savings. Of course, that only works if there's enough RAM for the buffer.

 

The speedups obtained from modifying code on the fly aren't usually so dramatic, but a cycle here and a cycle there can really add up. Unfortunately, even if only a few bytes in a piece of code need to be modified on the fly, it will necessary to either store a big chunk of code in RAM or else waste six cycles per "round trip" jumping between the RAM and ROM portions.

 

Both of these techniques can be used to some extent even in an unexpanded 2600. Combat, Donkey Kong, and Toyshop Trouble all make use of GRP0 buffers. A few other games create and execute small snippets of code in RAM. Both techniques, however, are much more effective when multiple kbytes of RAM are available.

[Mord]

Dangit, that's the real answer. You're suppose to tell them about magical sprite fairies and the electron gremlins first.

 

You see, there are several sprite fairies that live in the TIA chip, trying very hard to produce good graphics, however there are far more evil electron gremlins that reside on the motherboard itself. Those gremlins do their best to disrupt the good natured fairies from giving you an enjoyable game.

 

In a standard 4k cartridge, there lives more (about 1 for every 300 bytes, give or take.) sprite fairies, reinforcements if you will, that run to aid their trapped friends in the TIA. Obviously larger roms have far more fairies to help overpower the gremlins. And in a cartridge with built in ram, the fairies use those to help power themselves up, using it to disguise themselves to catch the gremlins unawares. A very useful tactic, and quite effective, as starpath games demonstrate.

 

 

--

Mord

[Lord Thag]

Fairies and gremlins? Bah! It's all straight nonsense. Here's the real deal, see, like my old grandad once telled it:

 

Most Atari programers have to make a deal with this old fella you meet at crossroads called the Devil, see. They make a deal with him (usually for souls, virgins and similar kind's o' things), so they can get to do powerful strange and incomprehensible hoodoo with registers and ancient, forgotten words of power like 'JMP' and 'LDA' which call forth the slumbering spirits, deep withing that ol' Devil's box y'all are callin' the Atari.

 

Unlike musicians, ol' Scratch usually challenges them to a game of Warlords or Combat, and let me tell ya, that ol' Devil plays a mean game of combat. He just challenges you to a match, and then (you not thinkin' and all) you grab that CX-40 to take him on without settin' the terms, and guess what? You end up playin' the bomber, and there goes your immortal soul. Still, some o' them lost souls can make some mighty fine music with that there Atari machine, and if'n you have some extra RAM lyin' around (like in that there Starpath), well, then you get a lot more space to work that hoodoo, see? More space = more hoodoo.

 

It's all devil's magic, in the end. Just make sure you choose the game variation if'n you run into the old goat. Ain't nobody likes bein' the bomber.

[mimo]

[Longhorn Engineer]

Fairies and gremlins? Bah! It's all straight nonsense. Here's the real deal, see, like my old grandad once telled it:

 

Most Atari programers have to make a deal with this old fella you meet at crossroads called the Devil, see. They make a deal with him (usually for souls, virgins and similar kind's o' things), so they can get to do powerful strange and incomprehensible hoodoo with registers and ancient, forgotten words of power like 'JMP' and 'LDA' which call forth the slumbering spirits, deep withing that ol' Devil's box y'all are callin' the Atari.

 

Unlike musicians, ol' Scratch usually challenges them to a game of Warlords or Combat, and let me tell ya, that ol' Devil plays a mean game of combat. He just challenges you to a match, and then (you not thinkin' and all) you grab that CX-40 to take him on without settin' the terms, and guess what? You end up playin' the bomber, and there goes your immortal soul. Still, some o' them lost souls can make some mighty fine music with that there Atari machine, and if'n you have some extra RAM lyin' around (like in that there Starpath), well, then you get a lot more space to work that hoodoo, see? More space = more hoodoo.

 

It's all devil's magic, in the end. Just make sure you choose the game variation if'n you run into the old goat. Ain't nobody likes bein' the bomber.

 

 

[+else]

Both techniques, however, are much more effective when multiple kbytes of RAM are available

 

That's it? Dang, why didn't Atari just release an expanded memory version of the Atari 2600? Call it the 2600+ or something instead of releasing the 5200. Course it never was like Atari to do things that made sense....

[Nukey Shay]

Both techniques, however, are much more effective when multiple kbytes of RAM are available

 

That's it? Dang, why didn't Atari just release an expanded memory version of the Atari 2600? Call it the 2600+ or something instead of releasing the 5200. Course it never was like Atari to do things that made sense....

 

Huh? The home computer architecture used for the 5200 is already more advanced than the 2600's (more ram, more sprites, etc). Why take a step backward? The only reason that Atari continued support for the little machine was because of the consoles that were already in homes. Releasing an upgraded version of it wouldn't make much sense (tho releasing emulator modules or providing backward-compatability does...in order to take advantage of the software library that's already been produced).

 

Perhaps the only reason that people continue to program for the 2600 is to see how far they can stretch the design limitations.

[Aegis]

 

Thanks for the technical (and not so technical ) replies people! I have to hand it to Starpath - the Supercharger was an amazing add-on for the VCS - wish I had one back in the day! Anyone who hasn't got a copy of 'Stella gets a new brain' should pick it up - for $5 it's worth every penny!

[+else]

Huh? The home computer architecture used for the 5200 is already more advanced than the 2600's (more ram, more sprites, etc). Why take a step backward?

 

I don't follow your logic. An enhanced 2600 would be a step backwards from the regular 2600. Humm -- how is that exactly?

 

The only reason that Atari continued support for the little machine was because of the consoles that were already in homes.

 

The only reason? How about the best reason! (I like to look at the glass as being half full instead of half empty)

 

Releasing an upgraded version of it wouldn't make much sense

 

Ummmm, well I hate to break it to you, but they did -- it's called the 7800. However, an enhanced 2600 would have tied Atari over until the 7800 was ready and offered backwards compatibility at the same time. The 5200 wasn't a wise move, as it required everyone to throw out the cartridge library and start over (sure, there was the 2600 adapter, but how many people honestly bought that?).

 

Basically:

 

2600 ---> 2600+ ---> 7800

 

Rather than:

 

2600 ---> 5200 ---> 7800

Edited June 13, 2007 by else

[Atari2600Lives]

I'm just scratching my head wondering how on earth they did it - kudos to Starpath's programmers - they were obviously an incredibly talented bunch!

 

A major key to getting good graphics out of the Atari 2600 is being able to get data out to the TIA quickly; this means minimizing the amount of time spent figuring out where data should come from. This leads to two types of optimization that can use up RAM very quickly:

• Having a buffer which holds the data that need to be output, in the order they'll be required, padded with zeros as necessary.
  
• Having code which can be modified on the fly as needed.
  

Pre-buffering data can greatly reduce the amount of decision-making that's required during a scan line. For example, suppose a game needs to display an object on a certain range of scan lines, and blank the sprite on the remainder. Using conventional methods would yield code something like:

  txa			; Assumes line counter is in X
 sbc p0_ypos
 cmp #16
 bcc load_it
 lda #0
 clc
 beq rest_of_loop
load_it:
 tay
 lda (ptr),y
rest_of_loop:
 sta GRP0
 ...rest of loop

That takes 19-20 cycles to handle one sprite. If there were a table set up that held the GRP0 data for every scan line (including the blank ones), the code could be greatly reduced:

  lda grp0buff,x; Assumes line counter is in X
 sta GRP0

That slashes the time from 19-20 cycles down to seven. A huge savings. Of course, that only works if there's enough RAM for the buffer.

 

The speedups obtained from modifying code on the fly aren't usually so dramatic, but a cycle here and a cycle there can really add up. Unfortunately, even if only a few bytes in a piece of code need to be modified on the fly, it will necessary to either store a big chunk of code in RAM or else waste six cycles per "round trip" jumping between the RAM and ROM portions.

 

Both of these techniques can be used to some extent even in an unexpanded 2600. Combat, Donkey Kong, and Toyshop Trouble all make use of GRP0 buffers. A few other games create and execute small snippets of code in RAM. Both techniques, however, are much more effective when multiple kbytes of RAM are available.

 

Very informative supercat. Thanks

[supercat]

The home computer architecture used for the 5200 is already more advanced than the 2600's (more ram, more sprites, etc). Why take a step backward?

 

Cost, for one. The 5200 was designed to be a cheaper version of the Atari 400, but it was still rather pricey. The 2600 could have been enhanced considerably while keeping the basic architecture and retaining compatibility. A few simple extensions that come to mind:

 

-1- 2K of RAM located from $0800-$0FFF.

 

-2- An option to run the CPU at clk/2 instead of clk/3. Nothing in the TIA's architecture would particularly mind the faster clock speed, though I think the TIA uses its own phi0 output to gate reads/writes.

 

-3- A third player, and maybe a fourth; also some more NUSIZx options.

 

-4- An option to split the left/right sides of the playfield (so as to have a full 40 bits)

 

-5- Maybe an option to delay the playfield output by 0-3 pixels.

 

-6- A selectable power-of-two divider for the tone generators.

 

The first option would require adding one cheap 'glue' chip plus a 2Kx8 RAM. The second option could probably be done with about 3-5 cheap glue logic chips. The other options would of course require an enhanced TIA.

 

Making a "plus" version of the 2600 should not have been overly difficult. My guess is that Atari wouldn't have wanted to cut into sales of the 5200, though.

[Nukey Shay]

I hate to break it to you, else...but the 7800 ISN'T an advanced 2600. There are two distinct modes of operation...one which provides compatability (and shares the same limitations), and one which does not.

[+else]

I hate to break it to you, else...but the 7800 ISN'T an advanced 2600. There are two distinct modes of operation...one which provides compatability (and shares the same limitations), and one which does not.

 

Sure. I suppose you could argue that maybe to a few geeks that fact might somehow have been important in deciding to buy a NES instead of a 7800 -- I'll give you that. But did the average Joe on the street know or care about that when deciding which system to buy next? No. To the average Joe, the 7800 was the next-gen 2600. That's the point I was trying to make. Most people don't care about the technical details inside of things.

Edited June 14, 2007 by else

[Nukey Shay]

I never said they did

I was responding to the statement that Atari should have released an expanded 2600 instead of the 5200.

While being Atari's second choice (due to the internal bickering over System X), what the 5200 had going for it was that the A800 architecture was already more advanced than it's 2600 predecessor, and that source code is virtually portable between the 2 systems. The latter point was probably very attractive to bean counters, as it would theoretically cut down on R&D cost (multiplied by the fact that Atari needed a next-gen system quickly to compete with Coleco). The only real question I have is why they didn't opt for full code compatability with the A800 software (unless the idea was to hide the fact that the 5200 was a repackaged 400).