Shooter game in silicon: inside the AY-3-8605 chip

Once again, another dedicated video game chip has been digitized and simulated! That makes a total of three dedicated videogame integrated circuits. This time it's the AY-3-8605 "Sea Battle" chip in a browser simulation. In this post I'll show a high-level overview of how it works, as well as share a few interesting things I found while working on emulating it. Let's dive in!

Background & Gameplay

PC-505 cartridges were sold under names such as Submarine, Sea Battle, Bataille Naval. (source/more info)

The AY-3-8605 was part of General Instrument's 8600-series "economy" line of game circuits. These chips provided the game logic to the numerous "PC-50X" compatible video game consoles, which were produced en masse in the late 1970s. These systems could play different games by swapping out cartridges containing different custom circuitry, such as the PC-505 cart which contains the focus of this post. Despite having interchangeable cartridges, these weren't true re-programmable systems like the later Atari 2600. The console only contained

A PC-50X compatible (Multicherry)

the power supply, TV interface circuitry, and controls while all game logic was located in the cartridges.




The gameplay and graphics are very simple, as they're generated by dedicated circuitry. One player uses their joystick to control a submarine while the other controls a destroyer ship. Just shoot your opponent with torpedoes/depth charges while avoiding their attacks. A few variations on this concept were presented as entirely different "games", such as a single player mode versus a simple AI, variants with an autonomous cargo ship to defend, or versions played with spaceships.

 

Die photos

The picture below is a photo of the silicon surface of the sea battle chip. Like the previous game chips I've looked at, this one was decapped and photographed by Sean Riddle over a year ago. The single metal interconnect layer is easily visible as lighter areas, while the other layers are mostly hidden beneath this. The polysilicon, vias, and diffusion traces are much easier to see and highlight in this picture, of the surface after the metal was removed with additional chemicals.

It took me about a month to trace out the different components using a paint program. This was then processed into a digital model of the circuitry (a netlist), which can be plugged into a simulator like the visual6502's. After a little bit of debugging it successfully generated screenshots of the original game.

The control panel (top), virtual chip (left), and video output (right)

You can check out the AY-3-8605 simulation here. Keep in mind that it's only meant for testing & debugging so I didn't bother to clean it up or make it user-friendly. Note: the ships won't show up unless you toggle the reset signal "on" for a hundred or so cycles.


Each green square is a single NMOS transistor, there are 2777 in total. If the metal on top of the gate is charged, electricity is allowed to flow through the source and drain below it, otherwise it's an insulator (this simulation is all-digital, as the chip is entirely digital except for some Schmitt triggers.) Connecting transistors together is accomplished through a single metal layer (grey), and N-doped silicon (blue.) It may seem rather complex, but it's multiple orders of magnitude simpler than modern CPUs which contain billions of transistors and well over a dozen metal layers.

Input/Output

Around the edges of the die are 27 rectangular pads which function as input/output. In a physical chip these would be connected through tiny bond wires to the package pins. The ground and Vcc (power) pins, on the middle of the sides, branch throughout the chip to support the logic inside. At the bottom is the 3.57954Mhz clock input pin which advances the circuitry. This is the NTSC colorburst frequency standard, used as a baseline for many old electronics. Note: this sample is actually a PAL-compatible chip, not NTSC.

The two directional control pins are in the upper-right corner. These are tri-state pins with Schmitt triggers, they regularly drain an external capacitor and measure the time it takes to charge, which is based on the rotation of the potentiometers in the controls. This may seem unnecessarily complex as the ships only have one possible speed, however it's necessary as the chip had to be compatible with the same controllers meant for pong-like games.

Four pins are responsible for the four different sound effects. The sonar and explosion effects have much larger driver transistors, presumably to increase their output current. There are a total of seven pins dedicated to video output: sync, colorburst location, the four possible colors (L-video, R-video, Background, Blanking), and hue. Another five pins are dedicated to game selection; three sense and two strobe, which multiplex six game select buttons.

A huge driver transistor to the right of a much smaller counterpart

Major features

Several major functional blocks are immediately visible. In the lower left of the die is a circuit that divides the 3.57954Mhz clock by two, and drives two alternating clock signals throughout the chip. Directly to the left of that is the horizontal counter, situated under its vertical counterpart. These use the steady clock to produce television sync signals, as well as determine the location of stationary game objects (scores, etc) These circuits are very similar to counterparts in the chips covered in previous posts.

The score memory logic (top) and drawing (bottom)

The score logic (upper-left) seems to be identical to its counterpart in the AY-3-8606. The designers at GI probably reused this design in most of their dedicated game circuits.


About a 5th of the chip is taken up by seven counters in the lower-right quarter of the chip. These counters store the position of the 5 game objects (cargo ship, destroyer, sub, torpedo, depth charge.) Five of the counters store the horizontal positions, while two store the vertical position of the projectiles. As all three of the ships never move up or down, their drawing logic is tied to the vertical sync counter rather than separate counters. These types of counters are called "slipping" or "jumping" counters. They constantly advance at the same rate as their sync circuitry counterparts (pun intended.) Once a field, they may either slip behind or jump ahead based on player input or game logic. This causes them to become slightly offset from the sync counters, which translates into a visual offset on-screen. Repeated slipping results in smooth motion.

Telling the vertical counters apart from the horizontal ones is easy (due to transistor size & clock signal.) Figuring out which game objects correspond to which counters isn't as easy based on static pictures alone. However, it's possible to see the different counters in action via the simulation. Watching the counters at work allows us to figure out which ones correspond to which ships/projectiles, as shown in the diagram below.

A few other logic blocks have been identified. At the top middle is a 5-stage ripple counter which turns the 15625 Hz horizontal scan frequency into 477 Hz, used by some of the sound effects. To the right of that is a lookup table and shift register which generate the different ship graphics, more on this later.

When hit, the ships flash their opponent's color

The four possible game colors come out on four separate pins but the colors of the ships can change during gameplay. Two logic blocks are responsible for managing colors. The first one decides if objects should be drawn in the left player's color, the right player's color, or not at all. The other rearranges the palette during the space games, and ensures that exactly one color pin is active at a given time. The colors are also dependent on external circuitry (such as an AY-3-8615 chip) which can itself be dependent on the selected game. One other note: the hue pin's affect on color is used to show contrast between the air and underwater.

 

Slow game logic

While debugging the simulation, I noticed that the submarine wouldn't move. After a little investigation it turned out that the sub's movement was simply disabled for a dozen or so frames after reset. The simulation wasn't being run long enough to enable movement. This and other "slow" behavior such as the cargo ship's movement, the sonar ping, blinking & loss of movement upon being hit, etc are controlled by the "slow" counter. This advances every 8 fields (~1/6th of a second) and takes longer to cycle around. Behavior like this is almost impossible to discern from footage, and would have never been noticed without die analysis.

To properly test the submarine's movement, I tied a checkbox (labeled Turbo) to the slow game logic's clock signal. Clicking it a dozen or so times advanced the slow counter enough to enable movement, much faster than running the sim normally for several fields. Not the most elegant solution, but it was easy to implement.

Ship generation logic

Amazingly detailed spaceships

There's one part of the die that I want to share in a little more detail. The ship graphics are a step up in complexity compared to the simplistic squares in the previous games covered here. Only five different graphics are possible though, one for each of the three ships and two for the two spaceships.

The circuitry to generate these stunning visuals takes up a non-trivial area of the die in the upper-right corner. The graphics are so simple that they don't use a ROM in the traditional sense, rather the shapes of the ships are decided by a look-up-table (green box.) A signal indicating which layer of the graphic is being drawn, along with a signal indicating if a space game is playing, travel into the look-up-table. Fourteen different signals are generated by this table (multiple active at once.) These mesh with three more signals determined by which ship is being drawn, before flowing into the output shift register.

The output shift register consists of twelve segments and six inputs. It's mirrored such that one signal controls the middle two elements, while one controls the ends, while the remaining four control the pairs in between. In short this means the look-up-table only has to hold the information to draw one half of the ship, which is then mirrored. This shift register is enabled whenever the counter of the currently drawn ship reaches a jump point.

The output of the shift register is put onto one of three wires (one per ship) which go into the first color matrix and collision detection logic. The output of the shift register can also be forced into an active state by use of the test pin, which results in horizontal bars like those in this screenshot. I suspect that the reasoning for this is to make any sort of aiming unnecessary when testing the collision logic during quality control.

Output of the chip when the test pin is active

Conclusion

The AY-3-8605 is a relic from a bygone era where video games were designed by electrical engineers rather than programmers or artists. The work done here will insure it will be still playable in the distant future when functional units become scarce.

A few things need to be done before it's playable. As the transistor-by-transistor simulation is too slow, the netlist will need to be converted into more abstract verilog using DLAET. That can then be ported to the MiSTer platform or converted into a software emulation. I'll also have to figure out the best way to re-create the behavior of the external analog sound circuitry.

Before that happens the AY-3-8500 has to be ported to the MiSTer. I've got it to run as a working core, however there are still issues with reliability which prevent it from being playable. Once I figure out a solution to that problem, I'll release the core and share some other things I've been working on since last time.

You can follow me on Twitter for the latest news related to the project. Also feel free to ask questions below. Have a spooky October everyone!