[Pong Project]

I don't see chip-level simulations as being very useful for playing these old arcade games. Most of the circuitry in PONG isn't doing anything 99.9% of the time, so why simulate it continuously? During vertical blank, the ball will move by amounts that are determined entirely by things that have happened earlier in the frame. The appearance of the net never changes, and the appearance of score digits only changes when certain specific events occur. Processing these things as display overlays rather than as logic would speed things considerably without affecting the user experience one iota (except by allowing the simulation to run real-time).

 

What I do see the simulations as useful for would be validating software emulators. Someone who studies the PONG schematic carefully should be able to produce a pixel-perfect rendition, but a failure to understand how something works could cause the look-alike to behave differently from the real thing. Even if it can only run at a frame per second or so (or even slower), it should be possible to set up a simulation script to compare the screens generated by full logic simulation with those generated by the look-alike program. Such a project could improve the acceptance of MAME simulations of hard-wired games.

 

Actually the technique I use to simulate the circuit only re-evalutes a chip when one or more of it's inputs have changed. Even with this the performance still isn't greate.

 

This was exactly my intention, as a tool for validating simulations of these machines. Perfect example of this was the Pong driver that was in MAME a while back. Althought pretty accruate it totally missed the fact that the ball keeps moving in attract mode. Even when I had studied the schematics I didn't relize this, and it wasn't until someone described the behavior of the real game was I able to correctly decipher the schematics to see how the ball behaved during VBLANK.

 

Dan

[Ball Horizontal Control Proposal 2]

BTW, I wonder how the layout was done? Is Pong a double-sided PCB?

 

Yes, Pong is a double sided PCB. I am going to guess that the lPCB ayout was done manually.

 

Dan

[Ball Horizontal Control Proposal 2]

I wonder if the horizontal ball control evolved somehow during the course of the design? The circuit I described seems simpler and more straightforward than the one Atari actually used, but perhaps it took people awhile to figure out exactly how they wanted the speedups to behave? If they started out with a more complex sequence of speedups and then simplified it, it may be that the complex circuitry had been needed earlier but wasn't in the end.

 

Another thing to consider is that there are no AND nor OR gates in the Pong circuit (but a lot of NANDs and NORs). If they were striving to keep the number of different chips down they would have had to add some inverters which would add at least one more chip. Also the inverted versions of V1, V2 and V4 aren't available so that may require yet another inverter chip to get these.

 

Given what was available in the way of signals and chips, the original circuit was probably the most straight forward even thought it may have saved a chip of two.

 

I would love to see schematics for some other Pong like game by either Atari or other companies to see different approaches to implementing the game.

 

Dan

[Ball Horizontal Proposal]

I offered two circuit proposals, but seem to have flubbed my descriptions. The first one was for two speedups (at 4 and 12 volleys, meaning three velocities total), the second was for three speedups (four velocities total).

 

Ah, ok, I assumed you meant that the first circuit had two speeds, instead of two speed ups. I'll have to draw that one up.

 

Dan

[Ball Horizontal Control Part 2]

 

Well V256 is active for six scan lines, and VSYNC is active for four, so I think I have the decodes right.

 

As for decoding the number of hits, I think I took care of that. If 0-3 hits, then only hit on line 256. If 4-7, hit on lines 256 and 258. If 8-11, hit on lines 256 and 260 (still two hits). If 12, hit on lines 256, 258, and 260.

 

 

In this, what exatly are VC1 and VC2?

 

temp1 = V1 nor V2 nor VC1 ; Low is good

temp2 =/V2 nor VC2

Move = temp1 nor temp2 nor /VSync

 

Dan

[Ball Horizontal Control Part 2]

djmips,

Yes, the number of horizontal lines when MOVE is high corresponds to the number of pixels the ball will move each frame.

 

supercat,

It's an interesting idea, although I haven't studied it carefully, I don't think it will work because it appears you will end up with MOVE being high for to many lines. Also you still can't get rid of the NOR and 3 NANDs right after the counter since you need these to decode the number of hits that correspond to each speed range.

 

With that said, I do recall reading an interview with Al Alcorn at one point that said if he had to do the design again, he could probably do the same game with even fewer logic chips then the original design.

 

Dan

[Hit Sound]

You are right, I missed part 2 of the Ball Horizontal control.

[Hit Sound]

Interesting that the length of the "hit" sound is generated based on the frame timing, but the score sound uses a 555. I wonder if there's a list somewhere showing what different chips cost in 1971-1972.

 

Also, I couldn't find where VPOS256 and VPOS32 are generated? Are those taps off the ball's timer chain?

 

Yes, VPOSxxx are taps off of the vertical ball counter. The 555 in necessary for the score sound since it's a much longer delay the could easily be generated with an existing counter signal. By using the counter in this circuit they saved themselves a chip and a couple discrete components (at least 2 caps and a resistor). The miss sound, which I haven't talked about yet, also uses one of the VPOS counters.

 

I do wonder why they used the vertical position counter instead of the main vertical sync counter. The only reason I can think of is that they were already driving to many chips off the vertical sync counter.

 

Dan

[Score Sound]

Yes, you would get a little audio glitch once per frame, but it probably isn't too noticable, and using 32V saved them from having to add more chips just to generate pure tones for the audio. All the audio circuits in Pong get thier frequencies from counters that are already used for other things.

 

Dan

[Game Control 2]

Can you explain a little more about why there would be an Antenna input? It seems a little bizarre.

 

The antenna input is quite common on early (and maybe later) arcade games. Without it, it might be possibled to trip the machine into play mode by giving it a static electric shock, which would give you a free game. The antenna input is used to pickup this shock and reset the machine, thus reducing the chance of someone getting a free game.

[Vertical Ball Pt II]

It's even more impressive to look at some of the later discreet logic games. I recently refurbished a Sega Monaco GP machine which was one of the last discreet logic games. It's amazing to think that game doesn't have a microprocessor. Actually in the case of that game I have wondered why they chose to go without a processor. It was released in 1980 and I can't image that it would have saved them any money going pure logic instead of a processor.

 

Dan

[Vertical Ball Pt II]

Great stuff I'd always wondered how games worked w/out a CPU.

 

Thanks! I was also quite curious about how they worked which is what led me to start writing this blog!

[Score Part 2]

New chapter is up now!

 

I takes me a while to put each chapter together since I am posting things as I go along. Drawing the schematics based on the really poor quality scans I have is the hardest part and takes a bit of time.

 

Dan

 

I like this blog! When is the next bit due?

 

It helps me learn how a Pong game works (i've got a broken Clone one here).

 

Thanks!

[Horizontal Sync]

This is really interesting stuff which I've never seen explained before.

 

I'm going to risk asking a question and sounding like an idiot.

 

Is the horizontal blanking period the time during which the electron beam is going back to the other side of the screen to start the next scan line? Kind of like a vertical retrace only a little shorter?

 

Instead of sending it back to the other side why didn't they just move it down one row and have it draw things on its way back?

 

Glad you are enjoying it. I am always happy to answer questions, although Eric did a good job answering these!

 

As Eric said, the horizontal blank signal is not used by Pong to turn off the electron beam, but it is used to signal the end/start of a scanline to other portions of the circuit. You are basically correct in saying the the hblank time is when the electron beam is returning to the other side of the screen.

 

My monitor theory is a little rusty, but I believe the main reason that the electron beam doesn't draw in both directions has to do with the way the analog circuitry of the monitor works. The voltage to the horizontal deflection coil rises slowly moving the bean left to right, then the sync signal causes it to drop rapidly which moves the beam very quickly back to the left edge of the screen. This rapid drop is also used to drive the flyback transformer which produces the high voltage that the monitor tube needs to operate.

 

Dan

[Horizontal counter]

Yes you are correct, the vertical counter counts to 262 lines before reset.

 

The 7493 is a four bit binary counter, but the first stage of the counter is not connected internally to the other three stages. The output of the first stage comes out on QA and the clock for the second stage is CLKB, so they need to be connected together to form the full 4-bit counter.

 

Dan

 

Interesting - 455 pixels per line.  That's a familar number to anyone who's worked with NTSC.  I'm going to take a guess that there is a similar vertical counter which resets after 262 lines.

 

One question; why is QA looped back to CLKB?