"real" processor speed?

[+Andrew Davie]

I got to thinking, well the 1.19MHz speed of the 2600 is pretty slow, so it's quite amazing some of the things that have been done with it. But then I also thought -- well, quite a lot of that speed isn't REALLY available to the programmer, as it's busy drawing the screen (what a decent video chip would be doing for us and letting the processor get on with important things). So if we take away all the ESSENTIAL things that the 6502 has to do to generate a frame, just what is the REAL processor speed available to us?

 

Assume we're generating a NTSC frame and that (say) only 192 of those are scanlines with background, sprites, etc. So each of those would take 76 cycles. That's (approx) 14600 cycles per frame. Let's ignore any time required for blanking, timer setup, etc. Now there are 60 frames per second on NTSC, so roughly 876000 cycles per second doing unavoidable housekeeping.

 

That leaves roughly 314000 cycles per second. So all the games we're seeing on this machine are basically running on the equivalent of a 0.3MHz processor WITH a video chip. I just thought it put things a bit more into perspective as to how much grunt you actually have with this machine. 0.3MHz of available processing power ain't a hell of a lot!

 

Cheers

A

[+grafixbmp]

I guess to top that off, no process can be done any less than 2 clock cycles either.

Just imagine with the task of unorthodox programing techniques, counting clock cycles and maximizing the use of memory... If only thoes attribues to 2600 programing were used with modern computers what they (programers) could REALLY pull off.

[Gemini]

Wait... I thought the TIA handled all the actual screen drawing? Yes, you have to manually code in what to display on each scanline through the 6507, but once that scanline starts drawing you can still make changes so that you can achieve effects like six-digit counters and asymmetrical playfields.

 

The 6507 is also lacking external interrupts so it doesn't make sense that it would be handling actual screen processing at the same time as game code.

 

I think the 1.19 MHz you get really is the true speed, you just have to burn some of it by a variable amount, depending on the complexity of what you want to draw on the screen.

[vdub_bobby]

Wait... I thought the TIA handled all the actual screen drawing? Yes, you have to manually code in what to display on each scanline through the 6507, but once that scanline starts drawing you can still make changes so that you can achieve effects like six-digit counters and asymmetrical playfields.

 

The 6507 is also lacking external interrupts so it doesn't make sense that it would be handling actual screen processing at the same time as game code.

 

I think the 1.19 MHz you get really is the true speed, you just have to burn some of it by a variable amount, depending on the complexity of what you want to draw on the screen.

Andrew's point, if I may be so bold, is that virtually every other computer and video game system has a video chip (i.e., Antic in the 5200, the PPU in the NES, etc.) that will draw the screen while letting the main processor continue to work on whatever else it wants to. Now, generally, you take a slight performance hit while the video chip is drawing the screen, but it isn't anything like the performance hit the 2600 takes; essentially halting all instructions to draw the screen.

[Tom]

Well, the point is, displaying anything halfways interesting eats up virtually all CPU time during the display period, leaving you with a ridiculously small remainder of CPU time during overscan/vblank.

 

(Edit: Bob was a bit faster. I had to stop typing and hold a video chip's hand).

Edited January 23, 2008 by Tom

[ibogost]

Andrew's point, if I may be so bold, is that virtually every other computer and video game system has a video chip (i.e., Antic in the 5200, the PPU in the NES, etc.) that will draw the screen while letting the main processor continue to work on whatever else it wants to. Now, generally, you take a slight performance hit while the video chip is drawing the screen, but it isn't anything like the performance hit the 2600 takes; essentially halting all instructions to draw the screen.

 

This is a nice summary of Andrew's observation, which I also appreciate, but there's something inexact about it that betrays one of the most unique things about the VCS. In fact, instructions aren't halted to draw the screen. Rather, it's just darned difficult to do much processing other than the basic operations needed to set up the next line or two of the display. However, this also makes it possible to segment parts of the screen and use the downtime for more logic processing rather than display processing (for example, during the blank part of the screen used for processing after bg and pf graphics were set up).

 

This isn't the same as the flexibility in a video chip, but it suggests a tighter relationship between the way logic/display processing works and the aesthetics of the games themselves. There's a perverse flexibility here that can't really be characterized in simple clock speed equivalents, although that's a nice way to shorthand it.

Edited January 23, 2008 by ibogost

[vdub_bobby]

In fact, instructions aren't halted to draw the screen. Rather, it's just darned difficult to do much processing other than the basic operations needed to set up the next line or two of the display. However, this also makes it possible to segment parts of the screen and use the downtime for more logic processing rather than display processing (for example, during the blank part of the screen used for processing after bg and pf graphics were set up).

True, but you could probably count the number of games that do something other than draw the screen while they are drawing the screen on one hand.

 

I can only think of one:

Pitfall II also plays music while drawing the screen but, of course, uses extra hardware on the cart to accomplish this.

 

Any others?

 

EDIT: Well, I suppose you could say that all the paddle games also read the paddles while drawing the screen, and TJ's trackball hack of Missile Command reads the trackball while drawing the screen. So let's say two hands instead of one.

Edited January 23, 2008 by vdub_bobby

[mos6507]

I think what you see in the VCS catalog demonstrates the lack of number crunching of the VCS. Most games on the VCS involve sprites that move in fairly predictable, steady, linear patterns (up/down/left/right). This is because it's very easy to just increment or decrement a counter each frame. It's almost like the old electromechanical games that predated videogames. That's why I'm more impressed when I see things like the graceful swooping and arcing in Demon Attack because I know setting up more complicated movements like those takes some doing on the VCS.

[Ben_Larson]

That's why I'm more impressed when I see things like the graceful swooping and arcing in Demon Attack because I know setting up more complicated movements like those takes some doing on the VCS.

 

in my (perpetually in development ) game 'incoming!', computing the X and Y shot vectors takes forever (in computer timespans at least) because I'm doing "poor man's multiplication" (i.e. just adding over and over). originally when I was doing this it was destabilizing the kernel for higher power shots because it was taking too long, so I had to modify things so that it did the computation in pieces. with power = 99, it takes 10 frames total to compute. i could probably do it in fewer, just haven't messed with it since it's working as-is...and i have a tendency to break things that are already working.

 

-Ben

[supercat]

True, but you could probably count the number of games that do something other than draw the screen while they are drawing the screen on one hand.

 

Sorry, my hands aren't that big.

 

A lot of games will do the pre-processing required for drawing complicated parts of the screen during earlier scan lines when they are showing simpler parts. In many cases this is done because of RAM constraints, but 100 cycles spent within the visible part of the screen are 100 cycles that don't have to be spent elsewhere for that purpose.

 

Actually, all three of my AA cart releases (including my contribution to the holiday cart) do a lot of processing on comparatively-idle scan lines:

• Strat-O-Gems uses the blank lines before each of the bottom 16 rows of gems to unpack and palette-map two color values for each of the six gems on that row
  
• Toyshop Trouble uses some of the largely-blank scan lines before each row of toys to set up the graphics and color pointers for both the toys and the elf on that row.
  
• The Stella's Stocking menu runs my BTP2 code on every scan line. BTP2 is a CPU hog, but I think the results are worth it.
  

Many other games do things like collision processing during the scan as well. Not huge amounts of processing, but not completely trivial either.

[supercat]

I think what you see in the VCS catalog demonstrates the lack of number crunching of the VCS. Most games on the VCS involve sprites that move in fairly predictable, steady, linear patterns (up/down/left/right). This is because it's very easy to just increment or decrement a counter each frame.

 

CPU time isn't the main difficulty with fancier motions. The bigger problems are development time and code space.

 

My LL demo manages to rotate a 43-pixel space ship to any of 256 angles and display it in real time (use select/reset to rotate the ship, but whatever you do don't press the fire button!). I forget what the exact CPU load was, but I did have some time left each frame. The motion is really crummy, but that's just 'cos I was lazy. Implementing gravity and thrust properly would not have required any particular processing power.

ll.bin