The AY-3-8606, another successfully simulated circuit

Since I began this blog it has focused on preservation of the AY-3-8500 "Pong on a chip" circuit (with one exception.) As has been said before, the tools and experience developed to emulate the AY-3-8500 can be used on other discrete circuits from the time period. The AY-3-8606 "Wipeout" game has now been simulated using said tools and experience, just like the '8500 was in August, and it took under two months to do so. This post describes the work done so far, and also documents some of its internals.

How to emulate discrete integrated circuits

I've talked about the process involved in past posts, here are the steps laid out again.

1. Obtain circuit specimens
2. Decap, photograph, and stitch images
3. Highlight images
4. Process images and correct errors
5. Simulate circuit in JavaScript, correct more errors
6. Run DLAET to abstract netlist into Verilog
7. Port to FPGA
8. Use Verilator to emulate circuit in MAME

At this moment, the AY-3-8606 is at step 5 and the AY-3-8500 is currently pioneering step 7. Thanks to Sean Riddle for undertaking steps one and two, which resulted in the images below. Note: All die photos on this post come from Sean Riddle under CC-BY-4.0.

You can check out the JavaScript simulation here. The simulation is purely for debugging purposes, so I haven't made much of an effort to make it user friendly. The files involved with the process are available here.

First impressions

The AY-3-8606 was part of General Instruments 86XX "economy" game system circuits. Like the earlier AY-3-8500, GI sold these chips to anyone wanting to build and sell systems using them. Many almost identical consoles were produced using the schematics and screenshots found in the catalog (page 460), these are now referred to as PC50x systems. The console contains the support circuitry, controls, color chip, modulator, speaker, etc while the interchangeable cartridges contain the unique game chips.

A standard PC50x system (pong-story)

The PC506 game carts went by "Wipeout", "Wipe-off", "Destruction Game", "Brix Game", or "Jeux de destruction" and contained an AY-3-8606 with it's pins mapped to the cartridge connector. 10 game variants, some two-player, can be selected using the console's buttons. Additionally, three switches could adjust the bat size, ball size, and speed of the game. Below is a table comparing it to the earlier AY-3-8500. It's a bit more complex, but not by much.

	AY-3-8500 (NTSC)	AY-3-8606 (NTSC)
Transistors	2318	2975
Nodes	973	1633
Polygons	10292	12435
Input clock	~2Mhz	3.579545Mhz

The AY-3-8606's surface.

Above is an image of the decapped chip's surface. There are a few noteworthy features immediately visible. Three wafer test circuits are present on the edges of the die. The text "© 1978 G.I. CORP." fills an empty spot in the upper-left. Nearby that is a collection of numbers written using different layers. Lastly "80-80395" appears in the bottom-right. None of these features affect the game logic, so highlighting them isn't necessary.

There is a repeating structure near the bottom right. This stores the state of the blocks inside six shift registers, corresponding to six rows of blocks. Interestingly, there are 10 segments per shift register, but only 8 blocks per row. More on this later.

Fixing errors

 

A high resolution look

The 2048*1810 images I used are clear enough to discern almost all features on the chip. The indistinct spots are resolved using the high-resolution images. Nevertheless little errors are made and need to be found. Four errors had to be fixed before my image processor would succeed. After it did the debug images then revealed over two dozen other errors. After a little more debugging work and modification to the virtual TV code, the JavaScript simulation produced the image below.

The generated image, along with the datasheet's rendering of game #9

It works! ...but not correctly. It looked like game #9 from the catalog, except some of the bricks were on the wrong side, the scores were vertical lines, and the bricks overlapped the top bounds. Time for more debugging!

Unlike some other chips, PC50x series games use strobed signals to read up to 10 different game select buttons with only 7 pins. It seemed that without external buttons the circuitry was changing to game #10 partway through a screen, explaining the misplaced bricks. I wrote a little code to simulate the external buttons via a checkbox, which fixed this issue. Because of this strobing the 8606 will probably exhibit odd behavior whenever multiple buttons are pressed, I haven't experimented with it though.

After selecting one of the other games, I saw that 9 columns of blocks appeared instead of 8! A close look at the shift registers revealed that they held 10 columns of blocks. The 10th column, which is off the right side of the playfield, is always reset to empty. The 5th column (middle) is reset to empty/full based on the game selection logic.

Take a look at this captured footage (skip to 4:14.) In game #9 the wall appears to be 9 layers thick (this confirms the catalog's screenshot.) So at least one game mode uses the middle column. It turns out that activating the reset pin (which the simulation does before loading) can only reset the blocks when the scanline is in a certain region. If you turn it on for longer it will correctly reset the blocks. This means that switching from game #9 to another one without hitting reset will leave blocks in the middle column, doing the opposite will create a gap in the middle of the wall. Also, the footage seems to suggest that the blocks do overlap the top boundary in real hardware. I don't have a physical console to confirm that this is the case, but the fact that little details like these are preserved is pretty impressive in terms of emulation accuracy.

This was causing the vertical lines. Can you see what's wrong?

The right player's paddle and score were missing (although I'd personally be fine competing against someone with no paddle), and the left player's score was still vertical lines. After a little more error hunting the output looked correct for all possible games. Odds are there is still an error or two present, but most of the circuit is correct.

Game 7

Looking at the circuits

I've explained some of the AY-3-8500's circuitry in great detail. My current focus is emulation, so I won't do the same thing for the AY-3-8606. Here's a short overview of different components based on what I learned while debugging it.

The 3.579545Mhz clock signal comes in through the aptly named clock pin at the top. This is halved and used to drive two alternating clock signals throughout the chip. 3.579545Mhz is the NTSC colorburst frequency, crystal oscillators at this frequency were mass produced for TV sets and thus made inexpensive by economies of scale. The non-NTSC 86XX variants, many later systems and even non-television chips used this standard frequency as a clock source or reference.


Next to the clock divider + driver is the horizontal and vertical control signals, just like in the AY-3-8500. The shift register is a little smaller though. All of the shift registers in the 8606 are more compact because they use capacitor-capacitor segments, unlike the AY-3-8500 which uses mostly capacitor-latch segments.

To the left of that is another horizontal+vertical counter pair. What this one does is a mystery to me, although I''m guessing it's part of the ball circuitry. Past those are the two paddle counters, one for each player.

In the lower-left is the score counter/display logic. It seems almost identical to the score areas on the 8600 and 8605 die photos. Another area of interest is the center where a game select PLA resides.

Next Up

The next step for the AY-3-8606 is to convert it to Verilog using DLAET. That will have to wait until I get the AY-3-8500 fully working on an FPGA. In the meantime, I'll be working on highlighting another chip.

You can contribute by highlighting! It's visual identification, not necessarily hard, it just takes a lot of time. The AY-3-8606 took over a month to highlight, while processing and error hunting took less than a week. Highlighting doesn't require much focus, so I worked on it whenever I needed to listen to something else. Shout-out to all the people who let me work on a laptop wherever one does not usually work on a laptop, you are preserving games you never even heard of!

What chips are next? plgDavid of the MAME team is sending off some chips to be decapped. He has the PAL variants of the 8603 (road race), 8607 (light gun games), and 8610 (improved 8600.) Hopefully useful die shots will show up sometime soon. If you have circuit specimens or the consoles that contain them (nonfunctional included) and wish to donate, I'll help with finding someone to decap them. I'm particularly eager to get die shots of Atari's chips, and the ones in Nintendo's Color-TV game series.

In the meantime, there are four existing die photos I'm looking at for emulation. First up is the 8600 (NTSC variant) which is pretty much an upgraded AY-3-8500 with more games and bidirectional movement. Second is the 8605 (PAL variant) submarine/warfare chip. Third is the MM57105, National Semiconductor's competitor to the AY-3-8500. It could play its games in COLOR (without a support chip.)

Die surface of the TMC0280

The last game chip to have been decapped as of 3/2019 is the MPS-7600, from the Coleco Telstar Arcade cart #1. I'm not doing this one anytime soon due to lack of any documentation, and also because its much more complex than what I've done so far (it has a custom microcontroller inside.) The fourth chip I'm thinking of emulating is the TMC0280. Never heard of it? How about the Speak & Spell? The TMC0280 is the voice decompression/synthesis engine inside it. It has a lot of transistors, but many of those are part of repeating arrays.

So which one to work on next? Comment below if you have a preference, or try highlighting one yourself. I'm leaning towards the AY-3-8605 because its a fairly unique game.

Two other things: first, I'm in the process of setting up a Patreon account for anyone wanting to contribute monetarily (all files and posts will still be public.) EDIT: here it is! Second, I'm going to be giving a talk at Latchup conference in Portland (Oregon) come May. Stop by if you're one of the 0.0086% of people around there. Anyway, my next post should be on the current/future progress of FPGA porting, so stay tuned (to channel 3 or 4. ;)

I ran the simulation for 10 million cycles while writing this (~1.4 seconds) The ball clearly moves, bounces and destroys blocks. (There was an error in the score logic)

"Febuary" Progress Update

I said I'd have another progress update in February, so here it is! I've made great progress on multiple fronts, and run into a few ongoing challenges along the way. For those uninitiated, I'm working on creating emulations of late-70's era discrete video game chips. You can find a more in-depth review in my last update.

Its funny to think how this project, which was originally just reverse-engineering the AY-3-8500, would have been completed months ago had it not been for me moving the goalposts. Here are my current long-term goals:

1. Create a FPGA emulation of the AY-3-8500(-1) for a FPGA system such as MiSTer

2. Make a software-only emulation of the AY-3-8500(-1) in MAME

3. Use the experience/tools gained to repeat the process for as many of the other 2 dozen+ discrete game chips out there

Lets take a look at what's been accomplished over the last month and a half.

FPGA emulation

As explained before, I've been working on creating a program to reverse-synthesize the low-level netlist of the AY-3-8500-1 chip into more abstract components which would be eventually converted into a Verilog circuit description file. This file can be used to configure a FPGA, a chip which contains mesh of re-programmable logic blocks. Current testing is done on a tinyFPGA-BX board, although I'll probably port it to something else (more on that later.)

The 972 nodes which make up the AY-3-8500 were reduced to 360 by the last update, it's now down to 318. That number is not very important, it just shows the reductions that are possible through reverse-synthesis. Those 318 components create a Verilog file which, after one or two manual patches, is programmed into the FPGA board via USB. Connecting the circuitry to a TV give us...

 

Squash, along with a visitor

...a game of "handicap"! Unfortunately it doesn't play or show the scores yet, as explained below. All of the virtual chip's pins have been mapped to the board's pins so attaching a grounded jumper to pin 4 will display a squash game. Grounding pin 5 will result in a tennis game, pin 6 Soccer, etc...

Tennis appearing sharp, albeit less retro on a digital TV

Below is the breadboard setup, on the left is the tinyFPGA board, andnext to it is a reset button. To the right of that is a 2x quad-OR gate, and past that  is a resistor network and controller circuits. The circuitry is almost exactly like the diagram in the manual, just with different value components and a direct composite connection instead of a RF-modulator. I goofed up and ordered a non breadboard-friendly RCA plug, which is why the connector dangles off the board (its connected to the two wires leaving the right side of the picture.)

Nothing a little soldering won't fix

As you can see, the current setup is not at all user-friendly, given it's composite-only output, support circuity, and cat-vulnerable mess of wires. This is because, the FPGA is currently emulating the AY-3-8500 and nothing else. If we ignore the 4 unchangeable pins and the voltage difference, the configured board can be pin-compatible with the original!

I'm planning on porting it to a core for the MiSTer FPGA retrogaming system, once I get a hold of a DE-10 Nano board to test it. This will eliminate the support circuitry and allow for VGA or HDMI output, among other things.

 

 

Challenges

The paddle inputs are currently not working correctly due to either an incorrectly configured pin or because the board is hooked up to wrong value potentiometers. The internal paddle circuitry is working as expected though (I tested this by adding code to trigger the pins based on the vertical counter, which is why the paddles appear above.)

The reason why the score display/playing capabilities don't work yet is due to a more complex problem. Almost all modern digital logic is synchronous, meaning registers only update when the clock signal does. Because signals with different latencies must wait for the synchronized clock, they won't trigger race conditions as long as the clock is no faster than the slowest signal.

The AY-3-8500 uses some more complex asynchronous logic along with "nasty tricks" such as pulse-on-edge circuits and latches which make porting to modern hardware difficult. Note that its difficult but not impossible. Working asynchronous logic can be created, in fact its an area of active research in semiconductor design. The problem is software tools can't handle it's unique needs yet, and the FPGA hardware blocks are built with synchronous logic in mind.

A "nasty" on-edge-pulse circuit

I believe this is possible though. Latches can be made inside FPGAs by combining many logic blocks. This is inefficient on resources, however the FPGA I'm using can already hold multiple copies of the AY-3-8500. Many of the "nasty tricks" can (and have been) eliminated during processing while keeping behavior identical. Lastly the AY-3-8500 only needs to run at a snailish 2Mhz which eliminates some of the problems associated with asynchronous logic.

That doesn't mean there won't be issues. For example, the logic which loads the score shift register is somehow being affected by component placement, despite the fact that it loads synchronously with ample time for signal propagation! This has had me stumped for a while. Hopefully changing the build tools from arachne-pnr to nextpnr will fix or offer insight into this issue. Also, I would like to thank David Shah and Claire Wolf (two of the developers) for taking the time to answer my (possibly bothersome) questions on these issues.

Another challenge: SABOTAGE!

Other Advancements

No software-emulation specific work has been done yet, although I have some good news regarding speed. I simulated the circuitry in a program called Icarus and measured the execution speed at 1/9th real world speed. This would only allow for playable emulation on PCs in the "overclocked i9 with water cooling" range, thankfully there are much faster methods of circuit simulation. Icarus runs by interpreting intermediate files, while Verilator works by converting the source into very high speed C++ code. It claims improvements of 100X, which seem reasonable given the actual work involved (I estimated that 75% of the AY-3-8500 cycles consist of merely incrementing two counters.) Once bugs have been ironed out via FPGA testing, I should be able to Verilator-ify the file and write a driver to interface it to MAME.

What about the other chips? Another one is currently in the process of being highlighted. Its the AY-3-8606-1 "Wipeout" chip which is a weird cross between pong and breakout. Unlike the well-documented AY-3-8500, I've only been able to find one video of it online. So far the transistor and via layers have been completely marked, and the diffusion layer is about 80% complete. Once highlighting is done, I'll pop it into the JavaScript sim for debugging before converting it to Verilog. Then, you know the drill, its onto the FPGA and into MAME.

The diffusion layer, about two-thirds highlighted

Another accomplishment: I contacted one of the engineers who designed the game chips at General Instruments back in the 'day. Unfortunately he doesn't have/know of any surviving design information related to the video game chips developed there. I do have a few questions to ask him sometime regarding the development process and the history behind the circuits, including the advertised but unreleased ones.

That brings me to something that popped up not long ago, an interview with the AY-3-8500's designer! Give a big thanks to Nate Lockhart for interviewing Mr Harrower, and Mr Harrower for agreeing to be interviewed. I'm looking forward to the follow-up on the Intellivision hardware development.

Well, these chips are not going to emulate themselves! It shouldn't be long before I have a JavaScript simulation of the AY-3-8606 and a more complete FPGA emulation of the AY-3-8500. In the meantime if you want see bouncing white squares, check out this impressive re-creation of the AY-3-8500 that Grant Seale made on an Arduino (or standalone micro-controller.)