Skip to content
  • About Me
  • Books
  • Photography
  • Papers
  • Security
  • Forensics
  • Essays
  • Christianity

Calendar

November 2025
M T W T F S S
 12
3456789
10111213141516
17181920212223
24252627282930
« Oct    

Archives

  • November 2025
  • October 2025
  • August 2025
  • July 2025
  • March 2025
  • December 2024
  • March 2024
  • July 2023
  • May 2023
  • February 2023
  • December 2022
  • November 2022
  • July 2022
  • May 2022
  • March 2022
  • January 2022
  • December 2021
  • November 2021
  • September 2021
  • July 2021
  • December 2020
  • November 2020
  • March 2020
  • September 2019
  • August 2019
  • August 2018
  • March 2018
  • March 2017
  • February 2017
  • January 2017
  • November 2016
  • October 2016
  • July 2016
  • April 2016
  • March 2016
  • February 2016
  • June 2015
  • March 2015
  • February 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • January 2014
  • October 2013
  • September 2013
  • June 2013
  • May 2013
  • April 2013
  • December 2012
  • May 2012
  • September 2011
  • June 2011
  • August 2010
  • July 2010
  • May 2010
  • April 2010
  • February 2010
  • July 2009
  • May 2008
  • March 2008
  • January 2008
  • June 2007
  • August 2006
  • February 2006

Categories

  • Apple
  • Christianity
  • Essays
  • Forensics
  • Gaming
  • General
  • Machine Learning
  • Music
  • Opinion
  • Photography
  • Politics
  • Security











Jonathan ZdziarskiNeat and Scruffy
  • About Me
  • Books
  • Photography
  • Papers
  • Security
  • Forensics
  • Essays
  • Christianity
Gaming

Arcade Hardware Hacking: Part I

On July 28, 2025 by Jonathan Zdziarski

Temple of Doom and TRON to JAMMA Conversion

Arcade Hardware Hacking: Part II

Arcade Hardware Hacking: Part III

I’ve been dabbling a bit in amateur EE this summer as my interest in rehabbing arcade games has recently hit a peak. It started with this 40-year old trashed Indiana Jones: Temple of Doom Atari System 1 board I found for cheap. If the seller says, “was working last time I played it, but don’t have the ability to test it now”, that’s code for “I backed over it with my car”, and “it’s trashed and I need plausible deniability for financial reasons”. Nevertheless, it’s a pretty rare find and was one of the three arcade games I remember playing with my dad at the pizza joint before he got too sick, so the game has a lot of sentimental value. Even broken, a complete System 1 with IJ board was a steal for a few hundred bucks. Over the course of a few weeks and hours of reading through schematics, I identified and replaced a total of 11 bad ICs – probably the result of a past power surge. I finally got it running 100% after fixing a whole laundry list of things: sprites, audio, VRAM, NVRAM, speech synthesis, FM synthesis, multiplexers, and address lines.

JAMMA. Why’d it have to be JAMMA.

JAMMA is an industry standard for arcade games, introduced to make it easier (and cheaper) to swap games and controls out without having to use an entirely different cabinet. It’s also what modern at-home systems (a “Super Gun” or a “Mini Gun”) use to play old video game boards on your own setup at home. A Super Gun interfaces with the JAMMA edge on a game board and supplies the necessary voltages and inputs, and plumbs the video and sound out to something that can be rendered on a monitor or CRT. My Super Gun (I own an Axunworks and a HAS, though I prefer Axunworks) sits on a coffee table in my office with an 18″ 1080p monitor, an OSSC Pro scaler, and four Nintendo Pro controllers using BlueRetro receivers. So as old arcade cabinets continue to rot, fall apart, or be exiled to the basement by now-married man-children’s wives, a conversion to JAMMA means that we can preserve some excellent games, allowing the community to play the boards on a modern TV without needing to keep (and upkeep) the very large wooden cabinets they used to come in – many of which were sadly generic. I usually mount my boards on acrylic to protect them at the front and back; this also lets me manage them like giant cartridges, rather than a stack of PCBs.

JAMMA Edge Wiring Pinout

Older games didn’t use the JAMMA standard, but whatever proprietary system the manufacturer came up with. Because there’s no JAMMA converter board for Atari System 1 games, I had to patch it into a JAMMA edge by hand. Most of this simply means reading the schematics and identifying what Atari System 1 pins map to which JAMMA edge pads. There was a catch though, specifically with Indiana Jones. After wiring everything up, I quickly found the directional pins were active-high (expecting +5V to a pin to move Indy). This is a problem, as JAMMA is active-low (grounding out the +5V on the pin to move Indy). Thus, my first foray into circuit building involved a 74LS04 (hex inverter, or less formally, “six NOT gates”) and a soldering iron.

74LS04 Pinout

ICs may sound a little intimidating at first, but 80s hardware was one of the most clean analogues for modern software. As you can see in the above pinout, your output is simply the NOT of your input. The 74LS series is a low-power logic class (Low Power Schottky) operating at 5v, with 2.5v being roughly the voltage that logic changes between true and false. So anything in the low voltage range (usually 0-1v) equates to false, while higher voltage (usually 4-5v) equates to true.

This is sort of what is meant by the term “active high” vs. “active low”; some circuits are switched when the voltage is low (using pull-up resistors), others high, depending on their design. The Atari System 1’s logic specifically for my IJ is active high, meaning Indy only moves when the voltage is high on the pins; the JAMMA standard is almost the opposite, where the corresponding pins normally float open at +2.5V when he’s not moving, and are grounded out when a button is pressed to make a character move. Hence the NOT gates were used to flip that logic. The LS04 receives 5v at its Vcc (“voltage at common collector”), and each output pin receives either close to 0v or 5v – whichever is the NOT of the input pin. When an input pin can be left floating, you should apply what’s called a “pull-up resistor” to bring it up to 5V, until it’s eventually grounded out when a button is pressed. I’ve been using 4K7 resistors for this, as it seems to be what many video game manufacturers also used.

You can see my little LS04 circuit on the smaller PCB. With the schematics in hand, some Molex wiring work, and a little op-amp from Amazon, I was able to play it on my coffee table. I still suck.

 

 

Hold on to your potatoes

This got me thinking, what other arcade boards are out there that don’t have JAMMA converter boards for them yet? Well, Disney’s third TRON movie, TRON: Ares, is coming soon… I’m really hoping they didn’t turn this one into a musical. So I decided to tackle an old TRON board from 1982. TRON is more involved a conversion to JAMMA, because the original arcade game has a spinner control. The spinner is driven by an optical encoder, which nobody’s really taken the time to reverse engineer. There are also a few smaller quirks with TRON. The video signal has a separate H and V sync, and so these need to be combined into a composite sync to work with a modern Super Gun. TRON also takes advantage of stereo audio, and requires both channels to hear all of the sounds (it actually has two synthesizer chips that operate together to generate music); JAMMA is inherently mono, and so the audio channels need to be combined. So to make TRON work, we need at least three circuits:

  1. A video sync combiner (H+V Sync = Composite Sync)
  2. A stereo-to-mono circuit
  3. A circuit to emulate the spinner control with a game pad

Additionally, an external amplifier is needed for sound.

There are a few other less significant things I discovered you don’t really need to interface with a JAMMA board; for example, the reset circuit requires +5v for only a few seconds when the game boots. I find that the game boots most of the time without it, and when it doesn’t, there’s a reset switch right on the main board that can be pressed.

Stereo to Mono

The first and easiest circuit to tackle is a stereo-to-mono converter. This can be built with just a couple of 470R (470 ohm) resistors. Each channel goes in at one end, and you combine the lines at the other end to make your mono circuit. The resistors protect the audio on the board from receiving too much current from each other; the audio channel could get damaged otherwise. I had initially attempted this with 1K resistors, but the sound was too quiet. Same with Indiana Jones, although I discovered later that the left and right channels in IJ are identical, so you can get away just using one channel.

Composite Sync

To build a composite sync out of separate H and V syncs, the two need to be combined such that the signal is only low when either H or V sync is low. A sync combiner is most commonly built as an NXOR circuit. For this, I used a different IC – 74LS86 (quad XOR IC). The LS86 is another simple IC that comes with four XOR gates, each with two inputs and one output.

75LS86 Pinout

To combine syncs, you’ll use two of the four XOR gates. For the first, you feed in H and V sync lines, and your output is the XOR of the two. Then, to turn it into an NXOR, take the output of that gate and feed it into another XOR gate on one input, with your +5v line as the other input. The output is a composite sync going to the JAMMA edge.

You want games? I’ll give you games…

Now we’re getting into the challenging bits of this challenge. How could we emulate the spinner control, so that Tron’s arm moves in any direction? I didn’t want to have to buy a spinner and use a different set of controls; what I wanted was to map one button to move his arm counter-clockwise, and another button to move it clockwise so I could play on a gamepad.

The schematic for the optical encoder shows a 74LS491 directly interfaces with seven pins that ultimately connect to J4 on the I/O board:

TRON Optical Encoder Schematic (Bally/Midway)

The LS491 IC is a 10-bit counter. Slightly more sophisticated than the other ICs, it maintains an internal state. Based on the schematic, it looks like TRON is only using seven of those bits (from the LSB, so values 0-127).

LS491 Pinout

From a software engineering perspective, think of logic chips as hardware analogues for functions, some with state. The LS491 maintains a counter state and provides crude APIs (its inputs) to increment, decrement, and set the state. If you are able to parse its output (think of it as an API contract), then you can interface with it in much the same way as a software function. In this case, our output is a mere ten bits, expressed across ten pins on the chip. We can safely ignore at least the top three MSBs, giving us seven. For an API, that’s not even a full byte!

After a little bit of experimenting in TRON’s Test mode, it looks like the game developers take an initial reading at boot, and sometimes at the beginning of each mini-game (like the tanks game), and then move Tron’s arm (or the tank turret) depending on whether that number goes up or down. Because those values could be anything whenever the pins are polled, there’s no specific value that corresponds to a direction. By default, whatever value it samples at the time it’s polled is mapped to 90° R. The act of turning the spinner quickly increments or decrements the value, telling the game to rotate left or right. You can go round and round, and since the board is ignoring the high 3 bits, it just keeps rolling over back to 0.

So an LS491 IC provides the interface (or API, or output – however you want to reason about it) to the I/O board, and however you decide to move that counter is going to determine what direction and how fast Tron’s arm moves. This gives you countless ways to design a control if you can read the LS491’s data sheet. The LS491 counts on the rising edge of the clock (CLK) pin, and the direction is determined by whether pin 9 (UP) is high or low. So both buttons need to pulse the clock, but one also needs to force the UP pin low. So whenever the CLK pin sees +5v, this is equivalent to calling a function to “do something”.

They haven’t built a circuit that could hold you

After a bit of trial and error, I put together a prototype board to test out. In Test mode, you can see the value of the encoder increasing or decreasing with each button press. I included an LS04 to invert the signal for UP, as I pull CLK low even when I pull UP high. As someone pointed out recently, however, I missed the fact that i could have used the last two XOR gates on the LS86 and eliminate the LS04 entirely. Just as I did with the composite sync, making one of the XOR inputs +5v turns it into a NOT gate for the other input.

In actual game play, however, you don’t want to have to sit there and mash the buttons 64 times just to turn Tron’s arm halfway around. Ideally, you want an adjustable clock pulse to do this for you. Now the buttons on a JAMMA interface are only polled at 60hz, meaning the fastest you could map a rapid fire would be 30 times per second (e.g. one pulse high, then one pulse low, 30 times). The turbo-fire options in the BlueRetro receiver I’m using allows me to roughly hit this limit, and surprisingly makes the game quite playable – even at higher levels.

 

Rotation at 30hz

 

Gameplay at 30hz

To get higher frequencies, a clock pulse is needed on the line itself, rather than on the JAMMA control line. An NE555 with an adjustable duty cycle and frequency can do the job. Placing it in front of the board, powered by an inverted control button line allows much faster rotation. I implemented this with a little timer circuit sidecar I had lying around (Video 3). An oscilloscope on this line tells me the video is somewhere in the 220hz range, which seems about right given the speed of the rotation.

 

Rotation at ~220hz

Positive and negative, huh? You’re a bit.

But it’s not necessary to go this far. Remember when I said the LS491 was a ten (seven) bit counter? What do we do to bits if we want to multiply them? That’s right, you can speed up the rotation by simply shifting the counter bits left. Doing this will double (or quadruple, etc) your rotation speed. Re-engineering the circuit isn’t even necessary. All you have to do is move the Molex pins connecting to the board over by one (and be sure to move the key pin over as well). The granularity you lose isn’t noticeable, but you gain twice the speed. This will allow you to control Tron’s arm with your rapid fire controls instead of having to tinker with a timer circuit. I like this much better. If you don’t want to have to hold down a button at all, just keep shifting the bits over until you get the push-button rotation you want. Shifting the LSB (J1 pin 1 in the circuit below) to the 16 or 32 position will cause his arm to jump in push-button increments. Again, you only need to play with the Molex connectors, and don’t need to change the circuit at all. The unused bits simply drop off, and the bits you’re using simply roll over.

I rebuilt the complete circuit in KiCad.

Initial prototype design

The rest of the JAMMA interface is simply connecting wires, as I said. The schematic has the layout, and there are some easier-to-read pinouts on Mike’s Arcade site for those looking to do the same. Unless you’re using a CRT, you’ll need something that can render in Scaler mode, like an OSSC Pro, to play this game as it runs at an oddball video mode.

It looks like Discs of Tron uses the same encoder interface, so this circuit will likely work in both games.

In the end, it’s worth the effort for a timeless classic.

 

It’s not the years honey, it’s the mileage

Shortly after the initial circuit, I finished a new revision of the interface board to add a low voltage amplifier and reset circuit, and make other improvements as I figure out KiCad a bit more.

Prototype interface board (Rev. 1)

The reset circuit is done with an NE555 timer chip. The goal is to deliver +5v on power on for roughly five seconds, and then shut off to boot the game. The power trickles from the small 103 capacitor into the large one, and when it fills up, power is equalized both on the trigger and the supply side. This flips a flop, cutting off the voltage so the game then boots. The duration can be lengthened by changing out the 4.7 uF capacitor for something bigger; I seem to get roughly one second per microfarad, so replacing it with a 10 uF gives me roughly ten seconds. If I use a 104 instead of a 103 capacitor, this trickle charges faster and gives me 4 seconds (4.7 uF) or 8 seconds (10 uF).

I plant the PCB stack on my coffee table, like one big cartridge, and so it’s easier to just use my finger to push the reset button when needed… but there’s something cool about letting the power-on circuit do it for you, just like there’s something cool about making a robot girlfriend that prepares your coffee in the morning (not that I’ve ever tried this). Nonetheless, someone installing a TRON board in a JAMMA cabinet may need a reset circuit like this when the physical button is out of reach. It’s normally handled by the MCR power supply, which I don’t use. I have found that, even with the reset circuit, sometimes the boot sequence is FUBAR. The watchdog timer on the actual board would, I believe, take care of this – but it’s quite a mickey mouse job that I have no interest in pursuing.

The amplifier is a simple LM386 op-amp. There are many instructions out on the Internet to wire these up. I found myself messing around with it until I got the ground correct; if you do it wrong you end up with a ground loop. The trick seems to be that both the audio return and speaker return must be connected to ground, as well as pins 2 and 4. Bridging a 10 uF capacitor between pins 1 and 8 increase the gain significantly.

 

Prototype design (Rev. 2), with amplifier and reset circuit

It doesn’t take too many parts to solder them together. A few resistors, caps, Molex connectors, and the ICs of course. It worked perfectly in my TRON!

Fabricated prototype interface board, assembled and operational

This type of board really is ideal for the test bench or a cabinet conversion, where you might want to wire up the MCR system directly to a CRT and controls. It isn’t ideal for an at-home JAMMA setup, though, because I still have to wire this board into a universal JAMMA edge.

I Took This System to its Maximum Potential

Now that I have a final design for the logic, the next step was to integrate it with a JAMMA edge so that you don’t have to Molex everything into a universal adapter. Instead of the spaghetti mess my test board is, there are now only four connectors + power going to the TRON board.

I’m showing you all of these to walk you through the evolution of a thought process. In reality, only a small number of these ever reached fabrication while I iterated on the design. I’m now experimenting with a final revision that removes the LS04 chip entirely, consolidates space, and groups Molex connectors by MCR grouping. I added an adjustable pulse timer, providing an easy way to set the speed of Tron’s arm without needing an external auto-fire, battery circuit, jumper headers for selecting between B2, B3, and B4 to assign to the two rotation directions, and other useful features.

I’m ordering a dozen in blue… and red ;)

 

TRON-to-JAMMA Edge Adapter, Final Design

Latest prototype arrived today. Tests correctly. One more prototype on its way, then I’ll order the production boards.

Latest prototype fabrication

It’s Time I Leveled With You. I’m What You Guys Call a User.

If you’re interested in digging into electrical engineering, I strongly recommend the book Electronic Devices and Circuit Theory by Boylestad and Nashelsky. It’s helped a lot in understanding why any of this works, and also been helpful in developing some basic non-IC circuits, such as the signal gate I am using in the final revision. There are many great references and HOW-TO’s online as well. Prior to this work, I’d done virtually nothing worthy in hardware hacking. Within a few weeks, and with modern technology, anyone can now learn how to build and fabricate their own printed circuit boards. I’ve only scratched the surface in what one can do here. Many of the principles in modern technology have remained the same over time – just changed in scale. This is a very fun hobby to be in, particularly if you love making things.

Bally/Midway made some really wise choices in how they handled the spinner and in how they bridged from the analog world to digital. A lot of engineering thought probably went into just how to capture the movements they wanted for TRON. Mapping the spinner to a pair of buttons works nicely, but is a different experience than playing with arcade controls. One of the things I love about this conversion board is that it provides everything else I need to make TRON work with any JAMMA setup, so I can still decide to connect a spinner control directly to the main board if I want to.

Other manufacturers, such as Sega, haven’t done nearly as smart work in this space. Outrun is entirely analog, requiring potentiometers for steering. This brings me to some other ideas for chips like the LS491. If I can use it to ramp up steering on a gamepad or joystick, then it could be used to drive a DAC (digital-analog converter), delivering the correct voltages to bring games like Outrun to modern controllers.

Final Production Boards

They’re here! The final boards look amazing. It takes about 30-45 minutes to assemble and solder. Well worth the investment to preserve a classic arcade game.

Rev. 1

As I mentioned in Part III, I wanted to replace the LS491 (the 10-bit counter chip Midway used) with two LS191s (4-bit counter x 2) due to the rarity and cost of the LS491. My revision 1 design incorporates these and makes a few other improvements, like adding a battery for high scores and enlarging the jumper connectors (they’re a real pain to solder!). I also simplified the design a bit by removing the gain switch, power LED, and a few other unnecessary components that bloated the board with extra parts (and time/cost to build).

 

Repository

The CAD for this file, along with other JAMMA adapters, can be found in the following repository, for non-commercial use only: https://github.com/jzdziarski/jamma/

Archives

  • November 2025
  • October 2025
  • August 2025
  • July 2025
  • March 2025
  • December 2024
  • March 2024
  • July 2023
  • May 2023
  • February 2023
  • December 2022
  • November 2022
  • July 2022
  • May 2022
  • March 2022
  • January 2022
  • December 2021
  • November 2021
  • September 2021
  • July 2021
  • December 2020
  • November 2020
  • March 2020
  • September 2019
  • August 2019
  • August 2018
  • March 2018
  • March 2017
  • February 2017
  • January 2017
  • November 2016
  • October 2016
  • July 2016
  • April 2016
  • March 2016
  • February 2016
  • June 2015
  • March 2015
  • February 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • January 2014
  • October 2013
  • September 2013
  • June 2013
  • May 2013
  • April 2013
  • December 2012
  • May 2012
  • September 2011
  • June 2011
  • August 2010
  • July 2010
  • May 2010
  • April 2010
  • February 2010
  • July 2009
  • May 2008
  • March 2008
  • January 2008
  • June 2007
  • August 2006
  • February 2006

Calendar

November 2025
M T W T F S S
 12
3456789
10111213141516
17181920212223
24252627282930
« Oct    

Categories

  • Apple
  • Christianity
  • Essays
  • Forensics
  • Gaming
  • General
  • Machine Learning
  • Music
  • Opinion
  • Photography
  • Politics
  • Security

All Content Copyright (c) 2000-2025 by Jonathan Zdziarski, All Rights Reserved. Opinions are my own.