Thursday, March 28, 2019

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)

Tuesday, March 5, 2019

"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 Clifford 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.)

Thursday, January 10, 2019

Progress update on AY-3-8500 emulation

Its been a while since my last post (about two and a half months) and you all are probably wanting an update on my progress. I've been meaning to do one for a while, in fact I have an old draft called "December progress update" that I threw out because it became outdated. If you're reading this, it means procrastination has lost a battle! (although the war rages on.)

To recap, approximately a year ago I started working on reverse-engineering the AY-3-8500 microchip. This chip was the "brains" behind millions of Pong-clone consoles sold in the later 1970s. Sean Riddle had decapped and photographed a specimen in early 2017, revealing the intricate circuits inside. About a month later, I expanded my goals from simply figuring out how it worked, to making a simulation of it. It took a few months to do, as I had to manually mark all the connections on the die images and write a program to process those into a netlist. An initial version was completed in August. Throughout September I participated in the RetroChallenge, making a few posts about how the chip operates, and getting distracted with something else.

In October I set a new multi-month goal, to make a full speed, playable emulation of the AY-3-8500. This would be done not by writing an emulator, but by writing a program to write emulators for me. This program (called DLAET) could be used to help emulate the numerous other discrete game chips out there. It works like a logic synthesizer in reverse, taking a list of transistors and turning them into more abstract components such as gates, shift registers, and counters.

Well, I have good news! A ton of progress has been done since I set out on this quest. I had expected a little more progress by now, however there were plenty of unexpected issues to deal with along with a thing called life. Anyway, DLAET can now (automatically) shrink the list of 972+ different components into a mere 360 components.

Latest debug image


For the curious, here is a list of specific components the circuit is reduced to:

1 NMOS-node (red)
22 IO ports (yellow or grey)
4 Pulse circuits (orange)
41 Flip flops/latches (dark green, dark blue, and sky blue)
20 AND gates
257 OR gates (grey or light green)
1 Shift register (purple)
8 Ripple counters (pink)
6 Counters (turquoise)
-----------------------
360 Total

Whats next


After a little more simplification work, I'll write the code to convert the (simplified) netlist into Verilog. For those unacquainted with EDA (Electrical Design Automation), Verilog is a hardware description language. Instead of a list of instructions for a CPU to execute, a HDL such as Verilog describes a list of physical hardware elements and how they interact. A Verilog description of the circuit could be put onto a FPGA, or be converted into a C code emulator.

The FPGA board I got
A FPGA chip contains thousands of reconfigurable digital building blocks, which can be connected together however the user desires. They can be used to mimic real hardware, including obsolete game systems. Programming a FPGA with the AY-3-8500's description, wiring up a circuit similar to one described in the manual and plugging it into a TV should allow me to play Pong like its 1976. Last November I bought a tinyFPGA board to do just this. Any relevant files will be posted online for anyone who wants to do the same.

My original goal was to create a playable, software-only emulation of the chip. Once a FPGA emulation has been accomplished, I'll work on using Verilator or homebrew software to convert the netlist into specialized C code. This will be then incorporated into a fork of MAME, allowing high-accuracy emulation on a normal computer.

More chips


There are over two dozen different discrete game chips designed and produced for early video game systems. Very few of these have had any attempt at re-creation, and for many of them datasheets or even play footage cannot be found online.  Normal emulation is not possible for the specialized circuitry inside them. Hopefully these 1st generation games will be emulated in the near future by me or by other people interested in them. The tools being worked on here are not specific to the AY-3-8500, they can be reused on other chips provided annotated images or netlist data is available.

The 4004 anniversary and visual ARM projects managed to obtain layout files from the companies behind their respective chips. Mask art (among other things) of discrete game chips might be in the archives of the manufacturers. Last week, I contacted Microchip Technology and Mitsubishi Electronics requesting any related files or documentation still available. Microchip technology is the descent of GI's semiconductor business, which designed many many chips after the successful AY-3-8500, some of which may be unreleased. Mitsubishi Electronics produced a few different chips used most notably in Nintendo's first consoles, the Color-TV game series.

So far nothing has been obtained. The email I received from Mitsubishi stated that they were "unable to provide (me) with information that is not available to the public via our website or publication." Microchip Technology has yet to respond to my email. I'll continue to attempt to obtain any manufacturer resources related to discrete game ICs.

Closeup of AY-3-8606 "wipeout" die
(Sean Riddle)
It is also very likely that layout/mask files have been lost or will not be released. In these cases the normal method of acquiring a specimen, decapping it, photographing it, then highlighting it will be needed. This is a chance for you to contribute! Any photographed chips have to have their components highlighted before being converted into a netlist. Highlighting a chip doesn't require you to know how the circuits are formed, it only requires you to identify different components on the basis of appearance. I believe the visual6502 team's tools worked on vector images, allowing people to highlight the images in a program like Photoshop or Inkscape. Alternatively the program I made works on raster images, which can be highlighted in MSPaint. Examples of highlighted images can be found here, here, and here. If anyone is willing to help annotate, I'll be happy to help guide and answer any questions.

Currently (to the best of my knowledge) die photos of five other discrete game chips exist. All of them can be found here. Other chips will have to be acquired and decapped (which you can help with too.) An (incomplete) list of game chips is here. If you have any that you can donate to preservation (nonfunctional ones included) that have not yet had internals photographed, one of the "acidbenders" could be contacted about decapping them.

To be continued


It seems like I don't have a thing for small, quick posts. Hopefully I'll write about many more accomplishments in the months ahead. Aside from this project, I have two other things I might sometime reverse-engineer and write about sometime. I also need to finish cleaning up and release my image processing tool. The next project update will be planned for February, although if you want the latest news I might post an occasional teaser on Twitter. In the meantime, I'll be happy to answer any questions you have in the comments below.

Thursday, October 25, 2018

RetroChallenge 2018 wrap up... and whats next

Retrochallenge wrap up


Retrochallenge 2018/9 is officially over, and judging was completed a few days ago. I'm proud of the amount of progre- Wait I won? I won! I won!!

Ok, I'm a little excited, I went in not expecting to end up in a top spot, being a rookie and all. Big thanks to John Linville and Michai Ramakers for hosting and judging the competition. Also huge thanks to all of the other contenders. As I said before, following along their diverse set of projects while my own progressed was the best part of the whole thing.

The sheer variety of projects really surprised me, with submissions that ranged from dealing with 1960s era "portable" computers, to 1990s era obscure gambling on the Super Famicom. Some mostly dealt with hardware, while others were entirely software (like Forth-ception) and some involved both. A few dealt with RE-engineering antiquated  tech, some involved building new-old software and hardware. A few had a history lesson mixed in (mine included.)

So what's next for the projects I've been working on? I started this blog to document reverse-engineering of the AY-3-8500, and most of it's circuits have been explained so far. Because of this, I'm moving REing it to a back burner in favor of a longer-term project. The chip simulation is very accurate emulation except for one major flaw, it runs at less than 1% of the actual hardware's speed. I considered making a simulation of it based on the datasheets, however this isn't true historically-accurate emulation, and the process wouldn't be easily repeatable with similar chips that are less thoroughly documented in datasheets.

The only way to accurately re-create some of these dedicated game chips is digitize the logic/schematic from die photos. Transistor level simulation unfortunately, is way too slow to be playable. One way to increase speed would be to implement the simulation in a faster language such as C++, the visual6502 team apparently tried this but didn't reach real-time speeds.

Last month I realized that the circuitry could be greatly simplified and still function the same way. Why say, simulate the dozens of transistors which make up a counter when you could emulate a counter with a few lines of code? Since the beginning of October, I've been working on a program called DLAET or Digital Logic Abstraction and Emulation Tool (pronounced "delete" or "dah-leet"). It works like a logic synthesizer in reverse, once done it will automatically convert low-level transistor netlists into more abstract logic, such as gates, counters, PLA, signal dividers, etc...
A debug image from DLAET. The green, red, and yellow wires are redundant,
and have been logically combined with the blue ones

The high level netlists will be converted in to high speed C code, which will emulate the logic in software. DLAET is not an emulator, it's a tool to create emulators from schematics/netlists. The chip I'm using for the initial testing is a >2000 transistor, 2Mhz chip (aka the AY-3-8500). I did some back-of-the-napkin speed calculations, which suggest that a modern CPU should be able to run the test chip at or above real time speed. I also put some thought into what emulation back-end the output code should be tailored for, and decided on MAME. I'll make a fork of it as soon as DLAET spits out some working C code.

The idea of an automatic logic abstracter has some other possibilities. Along with these discrete game chips, many ASICs in home computers and arcade machines. With moderate additions to the code, the digital portions of discrete game boards could be optimized to run much faster, or be emulated in the first place. The output code could also be modified to produce VHDL/Verilog descriptions of the chips put into them instead of C, allowing a physical emulation of the hardware.

Speaking of processing programs, I wrote a program to process image files into netlists back in spring. A cleaned up version of it will be put online, along with the source images for these various projects, to help anyone crazy enough to aid in digitizing these old chips. I stumbled across some similar programs online recently such as Oliver Gailbert's dietools. If only I found that back in February, I may have not created my own program from scratch, or at the very least; not name it "ChipTools" which sounds like a cheap knock-off.

Along with that project, I've worked a little on the SP0256 simulation since the end of September. Unfortunately its slow going, with no schematics, correcting errors involves finding something that isn't working as it should, then tracing the signals to suspicious looking areas. Whenever I make decent progress, I'll update it and post about improvements.

Looks like I've got no shortage of things to work on! I plan on posting updates every few weeks, so stay tuned. Along with these projects, there are one or two side projects that are unrelated to 1970s microchips I might end up posting about as well In the meantime, if you have questions or suggestions, hit that "comment" button below.

Sunday, September 30, 2018

Shifting bits: How a PONG chip generates on-screen scores

In this episode of my ongoing Pong-chip saga, we'll look into the circuitry that tracks and displays the scores on the screen. For those that haven't been following along, I made a simulation of the AY-3-8500 Pong clone chip in order to reverse-engineer and analyse its inner workings. If you haven't been following along I recommend you at least reading the post about the control signals. Oh! I have a little challenge for anyone capable: try to figure out where the score registers/decoding circuitry is in the simulation before scrolling down. (hint: the two players each can have a score from 0-15) Anyway, lets begin!

The part about history


The ability to track and display the scores on the screen was a big selling point for any consoles made with the chip (and thus the chip itself.) Prior to it's release, digital scoring was difficult to implement from a price/complexity standpoint. Arcade machines have a bigger component budget than home consoles, so they generated their on-screen scores with a handful of standard logic chips (e.g. 7400-series or CMOS equivalent), which made up a board containing dozens of chips. Early home consoles could only contain small numbers of chips or discrete transistors (the Magnavox Odyssey had 37 transistors and no ICs) to be competitively priced, so they didn't include features such as digital ball motion, multiple paddles, play-fields, and of course on-screen scoring. Many consoles instead had plastic sliders on them to keep track of scores, or had a simpler circuit in which every scored point moved a square across the screen.
The inside of the VideoSport MK II, showing standard
discrete system innards (photo: Andy Lewis)

Very few systems, such as URL's VA2 systems had these features, because they contained a real arcade circuit board re-purposed for home use. Most people probably did not want to pay 500$ for one of these systems though (2018 price: ~$2,300 or ~1765₤ or ~1979€ aka "very expensive" according to online calculators.) Electronics simply cost too much to allow home systems to play anything more than primitive analog Pong.

Technology was steadily improving however, by 1975 it was possible to fit thousands of transistors onto a single chip. Atari was the first to create and use a custom chip, allowing their systems to have on-screen scoring, color, sound, and digital ball motion at a very competitive price. They kept the chip to themselves though, giving them an edge over other home systems. General Instruments, a big semiconductor company, knew that the many companies that cloned the arcade PONG would want to follow Atari to the home market, so they designed a capable PONG (clone) and sold it to anyone. Thus the AY-3-8500 was born.
Circuit board of the Binatone TV master, a standard AY-3-8500 based system.
The circuit board is sparsely populated, yet it has many more features then the system above.
(From Dave Curran's blog post)
This chip began a family of LSI (Large Scale Integration) dedicated video game chips from GI and other manufactures. Now much more advanced game logic (such as on-screen scoring) was economically possible for home systems. Dedicated game chips were rendered obsolete the 2nd generation microprocessor-based consoles which hit the USA in ~1977. In many other parts of the world though, more advanced dedicated consoles were common into the early 1980s.

The score registers


The scores are stored in two 4-bit ripple counters, allowing scores from 0-15. Those with a good eye may have spotted them on the right side of the chip. Confusingly, the left counter holds the right player's score and vice-versa. I'm referring to these as "registers" even though they are not software-accessible CPU registers (the chip is in no way a microprocessor.)
The two score "ripple" counters

This  "ripple counter" isn't built like a standard ripple counter. In a normal ripple counter, each unit is made of a JK flip-flop connected to it's neighbors which serves as a divide/2 circuit. Each pulse will make the counter advance in binary order. This strange circuit also counts in binary order, it's wired a bit differently however. First, each unit is a little more complex, with multiple SR latches in them. This may make them behave more like JK Master-Slave flip flops (JK-MS flip flops exist where race conditions may be a threat to logic integrity.) Second, the increment signal is connected to every unit, and serves to disable their advance by grounding their carry signals. Because of this, only the top (LSB) counter will advance when the increment single is turned on, when it turns off the next bit is allowed to advance.

This pattern continues down the chain: Each unit is prevented from carrying unless all the units above (less significant) are in a "1" state. You can see this in the picture to the left, the vertical wires in the middle are the increment and output wires (A "1" = grounded) which are each connected through a green transistor to the lower (more significant) bits.

These 8 bits continue on to the decoding circuity. One last note, the registers will roll over to zero once a 1 is added to 15. A NOR gate below the registers will activate when all bits hold 1s, this prevents the score from "increasing" any farther, locking it at 15.

Decoding

The multiplexer

The 8 output wires from the score counters travel to the left in a "U" shape. These connections end in a multiplexer which selects which player's score is fed into the decoder. The multiplexer is a set of 8 NAND gates, four are powered by either the drawLeftScore or drawRightScore at any one time. The NAND gates are very simple, instead of a transistor with one side connected to ground, its side is connected to another transistor with it's other side connected to ground. Both transistors must be on to ground the output, making a NAND gate.


Following drawLeftScore leads to a flip flop controlled by horizontal control lines 6 & 12 (these are triggered at the center and left walls respectively.) The drawRightScore node is the opposite state of this. If you run the simulation, you should be able to see that the value going into the decoding circuitry will be switched to the other player's score at these points.

Above the multiplexer is a binary decoder (see below). One 4-bit value goes in, one of the 16 (24) output lines is activated (this is called one-hot as only one is active at a time.) To accomplish this the 4-bit value is inverted to make a total of 8 inputs, these much match up with the transistors to allow the output to be pulled high. At the top of the decoder are three transistors connected to the most, second most, and third most significant inputs. These transistors build a (bit3 AND (bit1 OR bit2)) gate. Numerically, this functions as a >9 check for 4-bit numbers, indicating if the circuitry should draw a "1" in front of the digit. We'll see where this "draw 1" signal leads to in a moment.

First part of the decoding circuitry. The decoder (right) turns a 4-bit number into one of 16 outputs (light blue)
These can trigger one of 10 inputs (yellow) into the encoder (left)

Some of the 16 possible outputs are ORed into 10 output lines as they travel to the left (with a NOT+NOR circuit) as the circuitry only needs to know the other digit. 13 and 3 are ORed onto the "3" signal, 12 and 2 onto the "2" etc. 6 is not ORed as there is no output 16. These 10 signals go into an encoder (left) indicating which 10 segments of the digit should be drawn.

Parts of the digits


The simplest way to turn a small binary number into a digit is to use a BCD (Binary-Coded Decimal) to 7-segment converter chip. This won't work in this case, as instead of sending seven signals to different lights, the circuit must turn a single signal on and off at specific times to draw a digit on a screen (plus BCD only goes up to 9.) There are probably many different ways to implement this, the AY-3-8500 achieves it by splitting the digit into five rows and three columns.
The different segments of the score, and their names.
The above diagram shows how the digits are split. I decided naming them with directions would make this easiest to follow. Note that the two red boxes are always on for any possible digit, and that the SW corner segment is controlled by the south segment, as it doesn't need to operate independently.

One thing that made me scratch my head for a while is the fact that the scores are not symmetrical, the rightmost side looks cut-off. This wasn't due to a bug by me as I found out, but by the chip's design. Looking closely at some footage (skip to 4:13 and look at the "11"s) I found that this exists in real chips, at least some revision of them.

Vertical score position tracking
Circuitry to track the current row being drawn is above the encoder to the left. The HsyncNOT_ON2 signal, which is toggled once per scanline, goes into a 2-segment shift register which functions as a one-quarter signal divider. Each scanline * 4 * 2 (due to interlacing) = 8 scanlines, thus each row is 8
scanlines high. This divided signal advances the 3-bit linear feedback shift register (LFSR) on the right, which keeps track of the raster beam's vertical position. This counter is normally kept at 0 unless the currently drawn spot is between vertical signal 7 (below sideline) and 8 (below score) due to a latch. This latch also directly disables the score output.

The 3 pairs of signals from the LFSR counter travel into a decoder where they activate from top to bottom (on the chip), the Top, Bottom, Middle, Upper, Lower, and Disable row signals (see picture). These five signals travel rightward into a matrix of specialized logic which compare them with the ten possible score-based signals to generate the right side, middle, and left side of the digit.


The logic matrix. The disable signal is present when none of the other vertical signals are.


This logic matrix is above, note that the right, middle, and left signals are active low. You can see how the constant segments are implemented, the two red transistors (connected to Vcc) force the upper and lower middle segments off, creating the holes in the digit "8" and every other digit. The right-side bottom and middle segments are grounded by the blue transistors and thus always on. The wide transistor t the left of the "Bottom" label controls both the left and middle segments, making the "South" signal affect both. Smart tricks like these reduce the number of transistors and die space needed to implement the circuitry, as both were at a premium in the mid-1970s.

The shift register


The last component in this chain of score circuitry converts the four segment draw signals (right, middle, left, and "1") into a single, timed signal. The chip uses a shift register to do this. Unlike the previous shift registers, this one takes in a parallel input and shifts it out serially. This shift register is located directly below the encoder and the encoder's inputs. Also unlike the previous shift registers, this one does not have an orderly repeating structure. Another interesting thing about it is that there are some "missing" transistors, spots where they look like they should be but aren't. It's possible that the designers changed the circuit after drawing part of it, and didn't remove the old traces from the layout.

A diagram for the score shift register
The shifter's operation is fairly straightforward, 10 wires with no pullup transistors function as capacitors. A load signal called at the left side of each score fills every other capacitor with the four possible values, plus one which is always low to create a gap between the 1 and the digit on the screen. The two clock signals alternate on and off during the width of the score at half the normal clock rate, first green on red off, then red on green off. Each toggle of the clock will cause half of the capacitors to override the capacitor to the right (with an inverted value). The bits travel from left to right so the "1" signal is output first, and the digit's right side last.

These bits control a large transistor (in the lower right in the screenshot above) which drives a wire leading towards the lower-left corner of the chip. Two other signals may disable the score output wire, the latch from the vertical circuitry, and a circuit that serves to hide the scores during some parts of the rifle games. The score output intersects with the field generation circuitry and goes to the score/field output pin. Outside the chip it is mixed with the other outputs and possibly given color, creating a viewable television signal. ...And thus, as advertised, digital on-screen scoring! (the '70s were a whole different time...)

And that's all folks! I'm glad I managed to get in a last-minute post before the RetroChallenge ended. I'm wondering how many others had 11th hour sprints... Looking ahead I've got some ideas for both a small and large project which I'll describe in a little more detail soon. For now, thanks for reading, and I hope you all had a wonderful September!

Thursday, September 20, 2018

A visual simulation of the SP0256 (beta)

Well... I got a little distracted over the weekend. For those that haven't been following me, I built a transistor level simulation of the AY-3-8500 Pong-clone System-on-Chip over the course of several months. For this September's RetroChallenge, I've been reverse-engineering chunks of it and posting my findings here. I'm sorry to say that I haven't worked on it at all since my last post, because instead of that I built a new simulation of a entirely different (and much more complex!) microchip; the SP0256.
The chip is HUGE! This is less than an eighth of it's surface

Well, its been a productive few days, here's what happened.

Along with the AY-3-8500, there are a slew of other antique chips I was interested in (e.g the AY-3-8600 series, the MPS7600, etc) and reading about, the SP0256 included. The SP0256 is an fascinating piece of circuitry, in short; its a speech decompression/synthesis chip. It was used in countless classic computer expansion cards, expansions modules for video game consoles, and an untold number of hobbyist projects. This particular one came from the Intellivoice expansion for the Mattel Intellivision. You can listen some sounds from it in the video below.

I would've love to mess around with transistor-level emulation of this chip, however the process of marking the components can take several months of work, and I think that I've done enough highlighting (for the AY-3-8500) already in 2018.

Then last Thursday I stumbled across this thread on AtariAge, where, lo-and behold another retro-geek had highlighted and cleaned up the entire SP0256 chip! Several months of work, already done, just ready to be turned into a simulation, thanks very much John PCAE! After finishing my last post on Friday I started creating a python script to remove curves in the image, which was partly unnecessary as it turned out. By Saturday afternoon I put the image into the image processor I built to process the AY-3-8500 (which I still need to clean up and release...), and after several errors were fixed, the program spat out segment and transistor definition files, which were actually larger than the source image.

Very late Saturday I put those files into a copy of my previous simulation code and turned the clock on and off. It didn't do very much at first. Toggle buttons and output displays tailored for the chip were added into the simulation. The next four days were filled with finding and fixing the bugs/errors in the source image, my python script, my image processor, and the simulation itself as well as learning more about the chip and the way it generates the sound.

And here it is, a (partially working) transistor-level emulation of the SP0256. Note the word "beta" at the top, there's definitely more work to be done. There are still plenty of bugs to iron out, chiefly the chip will not disable the instruction decoder while shifting a new byte in, resulting in several spurious instructions being (partly?) executed for every real one. Chances are that some wire didn't get overlain or processed correctly, I just need to find it (I've already managed to fix many other errors.)
You probably will have no idea whats going on (don't worry that's normal) I'll explain the workings more in-depth eventually, for now there are a few points of interest you can look at.

1. That big rectangle on the right is a 2 Kilobyte ROM containing a program to generate the generic phrases used by the Intellivoice, like "Mattel Electronics Presents". The chip supports internal and external ROM chips, such as game-specific ones inside the cartridges. The active selection column will change as the program progresses.
2. Here is a counter + decoder which generates multiple low level timing signals. If you let the chip go the control lines coming out to the right will pulse at regular intervals. Interestingly the lowest and third lowest signals are not connected to anything. The signal generator works almost exactly the same as the ones in the AY-3-8500.
3. The instruction decoder is here. Thanks to intvnut for figuring out which lines mean what opcodes, they are now named accordingly. The instruction set is listed on this page.
4. The clock circuitry is here, if not disabled by a low standby reset pin, it will advance the internal circuitry, as well as external circuitry through the ROM clock pin (lower left)
5. The chip outputs an analog sound waveform through a digital PWM pin (Pulse Width Modulation.) On the right hand side is a virtual oscilloscope trace of it, which currently only generates a repeating pattern due to stated bugs. Once the output starts working I'll add in a simulated analog waveform tracker, and possibly a way to export this sound to a file.

You may notice the simulation runs a little slower than the AY-3-8500 simulation, its a bigger chip (at least in complexity, not necessarily physical size.) A little comparison table is below
Name
AY-3-8500
SP0256
Logic Transistor Count
2353
15681
Nodes
973
4255
Polygons
10327
39432
Physical Size
???
~31.36 mm2
Die Photo Size (pixels)
2000x2048
8500x8469
Clock Rate
2.01Mhz
3.12Mhz
Pins
28
28
Process
NMOS
NMOS
Layers
4
4
Introduction Year
                                        

1976
Early 1980s

Wow, I'm amazed I got this all done in less than a week! I'll admit it's not as polished due to the rush, that will be fixed eventually. Next I need to get all the errors ironed out so the virtual chip can actually produce a waveform. I'm still going to work on the AY-3-8500 sim and talk about it, specifically the score circuitry next. Lets see what I can do in the next 1.5 weeks!
In the meantime, comment or ask questions below (come on, at least something went over your head.) I'm announcing my posts on twitter so give me an upvote! (Oops, wrong site.) If you want to see someone sail a sailboat while using an Apple ][ to obtain GPS coordinates or something along those lines, head to the RetroChallenge entrants list. And now to end this post with a few words of wisdom...