How Games Work: Late 70's CPUs and Framebuffers

[Seahawk]

This is the first of a series that will explain how game technology works an has evolved over the years, with a focus on the 'video' aspect-after all, a video game is not very functional without a screen to display on!

SPACE INVADERS is a game everyone recognizes as the first real smash arcade hit. It was so big it caused a coin shortage in Japan, and some people opened arcades with nothing but several Space Invaders machines. The game was as simple as it gets: shoot enemies, dodge bullets, and don't let the invaders land.

Two colors of awesome.

Wait a moment, what? This game is only two colors! Is that the best computer hardware at the time (1978) could manage?

Well, yeah actually, without costing a whole lot more to make. We'll even ignore the part where it was made by only one person (Tomohiro Nishikado). Let's see how this game accomplishes it's 'video' part.

What is a framebuffer, anyways?
The way a framebuffer works has changed a lot in the evolution of games. For our purposes here, it is a special section of memory that corresponds with what is directly displayed on the monitor.

Too confusing? Ok, think of it as a sheet of blank graph paper.

Pictured: Space Invaders

Each square is a bit of memory. Like an actual bit, each square has two possible states: empty or filled. The point of any video game (or any modern GPU) is to fill the right squares to give you the visual feedback you need to keep your squares from forming a giant GAME OVER in your face.

Still sounds easy? Fine, let's say I am the CPU of a new game called Space Invader. There is only one tank and one invader. You cannot move, and you can only shoot. My job is to draw everything on the screen. I have done my job and have created a 1:1 scale drawing of some objects in Space Invader on graph paper.

Pfft, who needs computers?

After drawing the picture, I have to decide whether or not that shot from the tank is going to hit the invader. Hmm, based on that trajectory I'm going to say that yes it did hit the invader. So now, I have to erase the picture, and redraw a new picture reflecting what has occurred.

Pew-pew!

And that's the basic flow of my game.

1. Draw the picture.
2. Decide whether the tank shot a bullet.
3. If there is a bullet, move bullet upwards.
4. If there is a bullet, decide if bullet collides with invader.
5. If there is a collision, erase the invader and the bullet and draw explosion.
6. Erase the picture.
7. Go to #1

Wow! You know, the decision making is pretty easy, but drawing and erasing and redrawing pictures is pretty time consuming. I would definitely hate to draw and redraw 5 rows of 11 invaders each, with three different types of invaders, and the invaders' bullets and my bullets and moving invaders and tanks and *gives up and throws paper away*.

You get the idea. This is hard work! And there's not even any color! I sure wish I had a way to speed up this process. But in the 1970s, this was all there was.

HAL: Who's laughing now, human?

This is how many 70s games worked (Gun Fight, Space Invaders + ripoffs/bootlegs, more). Process logic, make a picture of it, and spit it out to the screen. And let's go into numbers now.

Space Invaders has a CPU (Intel 8080) that runs at 1,996,800 Hz. (Some more informed readers may notice that that CPU speed is faster than the freaking NES) The game graphics are 260x224 pixels at 59.54 frames per second. Let's round that up to 60 for simplicity's sake.

260x224 = 58,240 pixels on screen.
58,240 * 60 = 3,494,400 pixels total to be drawn. Per second.

Well, that's more pixels than cycles per second. How on earth can we manage that?

Wait a second......there's a lot of black space at the top and bottom of the screen that doesn't need to be fill or drawn, ever. Let's skip looking at those areas. Hmm....and those words SCORE<1>, HI-SCORE, SCORE<2> don't need to change ever. Let's skip those too. And that lives counter and CREDIT doesn't need to change every frame, so we can skip those too (most of the time)!

Game development back then was all about finding shortcuts like these, anything to reduce the burden on the slow (relatively speaking) CPUs at the time.

But wait Seahawk, there were plenty of computer games before Space Invaders!!!

True, but most of those were run on very large university mainframes by bored computer students, who displayed there games on strange things like oscilloscopes and radar monitors. I don't even want to think about the black magic that went into doing that.

But what about PONG?!And many other earlier arcade games?
All right, fine, you win. I'll tell you some stuff.

Of course, Space Invaders was not the first arcade game ever. The earliest arcade game I can think of that uses a CPU is Gun Fight.

However, there were even earlier games that have no CPU. Games that have stored program ROMs and no digital components. Games that are just a bunch of resistors, capacitors, and wires planked together.

This is Pong. See a CPU there? I don't.

Not impressed? Here, have some schematics of a game called Space Race. Hope you have that degree in electrical engineering handy.

Pictured: Black magic.

See the FULL SCHEMATICS HERE. And while you're at it, here's a self-help guide to get you started on your own analogue game. And here's Atari's guide to servicing machines. More info on analogue games can be found here.


Of course, things didn't stay like this forever. Eventually someone had the brilliant idea of splitting off all graphics duties into a completely different device! And thus the Graphics Processing Unit was born. But that is definitely an article for another day.


So, I hope this article was informative on how the most ancient of games worked. If you learned something today, then it was worth it. Feel free to ask questions =).

[Kong]

Interesting. I think if you do more then you should also chronicle the evolution of development teams. How we got from this

it was made by only one person (Tomohiro Nishikado).

To where we are today with multi-million $ projects made by hundreds of people over several years.

[Demon-Mask]

Quite a nice little article. I love how the caption for the schematics to Space Race says "Pictured: Black magic."
How did anyone ever figure out how the lay out the components to create a game?
If you didn't already know how to, it'd be a bunch of luck/trial and error.

[Seahawk]

Originally Posted by Demon-Mask

Quite a nice little article. I love how the caption for the schematics to Space Race says "Pictured: Black magic."
How did anyone ever figure out how the lay out the components to create a game?
If you didn't already know how to, it'd be a bunch of luck/trial and error.

To be sure, a lot of those circuits could be reused from previous games or even non-game efforts. After all, things like the coin counter and the generation of a basic television signal don't necessarily need to be custom made for each game.

That honestly doesn't really change much though because without a CPU the developer is tasked with making what amounts to a giant finite-state machine without the benefits of a stored program. In the analog world (and what I think is the bigger problem) you must also make sure the voltages play nice with all of the components so that nothing will fry. With digital circuits this is MUCH easier.

And thanks for that feedback on the article, I thought nobody was reading it =).

[Demon-Mask]

Yeah, analog circuits are prone to errors with voltage and making sure you have the resistance just right. Too high, and it doesn't work, too low and you can completely ruin anything after that point in the circuit.

Coin counting and signal generation, I know are reused, it's how they discovered that the other combinations of components would make Space Invaders that impresses me. They didn't have many games to use as an example.

Finite-state machines aren't all that good for much, at least not anymore.

[PAQ]

Originally Posted by Demon-Mask

Quite a nice little article. I love how the caption for the schematics to Space Race says "Pictured: Black magic."
How did anyone ever figure out how the lay out the components to create a game?
If you didn't already know how to, it'd be a bunch of luck/trial and error.

Demon mask, the design is split in simpler parts. For example, in the first page of space race we can see (from top-left to bottom-right)
- Power supply (convert mains to 5V) (8-7 D)
- The start-game mechanism (6-3 D)
- Player 1 and 2 score counters + mutiplexer (8-7 C)
- Oscillator (clock generator) + screen horizontal and vertical reset circuitry (6-2 C + 6 B)
- "3D Video Card!!!" (5-3 B)
I could go on... The thing is, we engineers dont like complicated things. We prefer to split a big problems in smaller parts, and solve each of them separately.

Randomly placing components would just frustrate everyone...and besides...who likes to do things without knowing what is doing?

Originally Posted by Demon-Mask

Yeah, analog circuits are prone to errors with voltage and making sure you have the resistance just right. Too high, and it doesn't work, too low and you can completely ruin anything after that point in the circuit.

Coin counting and signal generation, I know are reused, it's how they discovered that the other combinations of components would make Space Invaders that impresses me. They didn't have many games to use as an example.

Finite-state machines aren't all that good for much, at least not anymore.

Thats why a marvellous thing, called feedback, was invented. [ame="http://en.wikipedia.org/wiki/Negative_feedback"]Negative feedback - Wikipedia, the free encyclopedia[/ame]
The problems of analog circuits are:
- Size
- Power consumption
- Noise, in noise sensitive applications (this is taken care in modern analog noise-sensitive applications using cooled electronics)
- Harder to connect stuff (impedance matching).

Cheers

---------- Post added at 03:46 PM ---------- Previous post was at 03:36 PM ----------

Originally Posted by Kong

Interesting. I think if you do more then you should also chronicle the evolution of development teams. How we got from this
To where we are today with multi-million $ projects made by hundreds of people over several years.

That one is simple: there was more money involved (more players). The rest comes automatically (more companies, more competition, etc...)

[samejamesbond]

That was a fantastic article Seahawk, I'm not too familiar with game
scripting/programming. I figured it would be based on simple graphics, but
you did go into very nice details on shortcuts.

I'm curious, how did audio work back in the day? I'm particularly curious
about how the audio would speed up as the invaders got closer and closer.