Professional software development, amateur BMW tinkering, old arcade game stuff


Arcade Classics That Deserve A Revival

Arcade franchises are going through a revival period currently in the world of gaming. We’ve seen many of the biggest classic titles brought up to speed in the modern world: Mortal Kombat and Street Fighter are consistently popular franchises, and titles like Rampage have even made it onto the big screen (in a surprisingly decent film, at that). But not all of the arcade classics have been so fortunate – some are still left behind. This is of course understandable, as there’s not a market for any and all classic games form the past. Still, we think it’s time some other arcade classics get their turn in the spotlight.

The following are a few that stand out….


Long considered the king of arcade sports titles, NBA Jam is a franchise that holds a special place in the hearts of many. Beloved for its over-the-top antics like flaming basketballs, insane trickshots, and of course, the ridiculous dunks, NBA Jam brought an extra sense of silly fun to a genre that hadn’t seen anything like it before, and that hasn’t since. While there have been sporadic attempts to revitalize the series (including through a modern mobile app), none have had the same spirit of the originals, which is a true shame. For this reason, we’d suggest the game needs to go home to where its original developers are now: Netherrealm. The Mortal Kombat developers made the original NBA Jam what it was. Surely, they could bring it back to life.


Since the 1981 original, poor Frogger hasn’t had a great run of it. He spent time trying to steal Mario’s and Sonic’s thunder with a new mascot-ized 3D design, and also had his game rather shamelessly copied by the mobile title Crossy Road, which has gone on to become a hit in its own right. As a result, we think the arcade genre’s favorite frog deserves another chance at redemption. The question is how to do it. The simple answer is that a mobile arcade could resurrect the original game, but one has to assume this would have happened by now if it were ever going to. Another option that comes to mind is injecting Frogger elements into a different genre – specifically, modern casino gaming. Among slot games offered at U.S. sites, there are actually some character-specific games that do a good job of incorporating themes and mini-games (with characters from Greek gods to Jekyll and Hyde), and one could imagine some approximation of the classic Frogger arcade blending in with a slot arcade.


Golden Axe

In an age of beat-em-ups featuring street thugs and dingy alleyways, Golden Axe took the genre in a different direction – one that’s still fondly remembered to this day. The side-scrolling medieval romp let up to three players crusade together through fantastical lands, beating on the armies of the evil Death Adder while looking for the titular weapon of power. With a number of games under their belts, Ax Battler, Tyris Flare, and Gilius Thunderhead are well remembered names from the arcade era, but have now been missing for over a decade. With other beat-em-ups like River City Rampage and Streets of Rage receiving reboots, we think it’s time Golden Axe got the same treatment. It could even be done via mobile (which is true of most of these games, really), and for that matter the aforementioned themed slot idea could at least put these characters back on people’s minds!


The mouse cop dealing with a lot more crime than he bargained for might not be the most well-remembered of Namco’s golden era of arcade cabinets (Pac-Man and Dig Dug hold that title). But Mappy’s certainly one of the best of them. The fun and frantic cat-blasting title is a favorite of many old-school arcade-goers (in no small part due to its super-catchy music), but has seen little outside of a few low-effort mobile titles since the 1983 original. A new Mappy has a lot of potential if done properly, especially if the developers lean into the lovable character designs of the original. We’d just hope they find a way to tap into the original music.

Dragon’s Lair

Let’s end this list with an oddball selection: Dragon’s Lair is a very unique arcade title in that the entire game is animated by hand, as though it were a classic cartoon. Animation legend Don Bluth was responsible for the magnificent artwork featured in the game, and the game been cherished as a unique and sought-after title for decades as a result. However, barring some decidedly sub-par sequels, it’s been just as long since Dragon’s Lair has seen any new worthwhile content (unless you count its significance in season two of the hit show Stranger Things)With the novelty of the original having long since expired, we think Dragon’s Lair should go in an entirely different direction: full-length animated film. Seeing these classic characters brought back in the style of the originals would be a perfect way to honor their legacy, while also introducing more classic hand-drawn animation into a world sorely lacking it.


Sega Space Harrier arcade pcb repair

A classic game, and a massive pcb set – CPU board, video board, ROM board and audio board.  The game can be bench tested with just a +5V supply (no need for +12 or -5) but power has to be run separately to each board.  (Forgetting to power the ROM board will give bad or missing sprites!).

This board played fine except only put video out in the blue channel.  A couple of resistors had been clipped out near the video connector but this seemed to be a previous attempt to debug the problem rather than the cause of it.  The real problem was nearby though, the HC273 @ IC111 had failed with all the outputs stuck low.  IC111 handles green & red channels, IC104 handles blue.


Next problem was lack of sound samples – speech & drums.  Synth music worked fine which pretty much guaranteed the sound CPU and program was running properly.  Samples are played by a DAC chip on the audio board, and the samples ultimately come from the ROM chips.  You can think of this process in two halves – the part of the process that sets up the address lines for the ROMs, and the part of the circuit that uses the data that comes out of the ROMs and feeds it to the DAC.  A logic probe showed all the address inputs pulsing as expected, as well as the data output at the ROMs.  The DAC inputs were mostly low, except for some random bursts of static now and again, which at least proved the amplifier was working.  I have to admit I don’t really understand what the circuit involving the DAC data does – there are a bunch of sequential adders and the top bit of the highest adder is what clocks the DAC.  It seems the adders were working but couldn’t ‘count high enough’.  Eventually I found a single dead pin, which was a corroded trace underneath one of the IC’s – what a crazy fault.  With that patched, sound was perfect.


Finally inputs were tested, and the analog joystick inputs didn’t seem to function (each axis can be tested with a 5K pot).  On this board the CD4051 chip at IC125, which is used in converting the analog inputs to digital, was simply missing.  It was cleanly removed so a previous owner must have scavenged it to fix something else.  This part is easily available and a new replacement was ordered, and the game worked perfectly.

20190210_124826 20190219_184225


Pinout info from


CPU BD (834-5797)G(AMP 50P)操作系G (AMP 50P) operation system
A14 SHOT 3A14 SHOT 3
A15 SHOT 2A15 SHOT 2
B14 SHOT 1B14 SHOT 1
B24 +5VB24 + 5V
B25 +5VB25 + 5V
H(MOLEX 6P)モニターH (MOLEX 6P) monitor
J(AMP 10P)電源J (AMP 10P) power supply
A1 +5VA1 + 5V
A2 +5VA2 + 5V
A5 GNDA5 GNDB1 +5VB1 + 5V
B2 +5VB2 + 5V

●CONTROL BD(834-5798)● CONTROL BD (834-5798)K(AMP 10P)電源K (AMP 10P) power supply
A1 +5VA1 + 5V
A2 +5VA2 + 5V
A5 GNDA5 GNDB1 +5VB1 + 5V
B2 +5VB2 + 5V
●ROM BD(834-5800)● ROM BD (834-5800)M(AMP 10P)電源M (AMP 10P) power supply
A1 +5VA1 + 5V
A2 +5VA2 + 5V
A5 GNDA5 GNDB1 +5VB1 + 5V
B2 +5VB2 + 5V
●SOUND BD(834-5903)● SOUND BD (834-5903)K(AMP 10P)電源K (AMP 10P) power supply
A1 +5VA1 + 5V
A2 +5VA2 + 5V
A5 GNDA5 GNDB1 +5VB1 + 5V
B2 +5VB2 + 5V
B5 GNDB5 GND(MOLEX 6P)サウンド出力(MOLEX 6P) sound output
1 SP_L+1 SP_L +
2 SP_L-2 SP_L-
3 SP_R+3 SP_R +
4 SP_R-4 SP_R-



Capcom Ghosts and Goblins arcade pcb repair #2

The game played but background tiles were clearly wrong in places as were some of the sprites.  As the game has relatively few tiles I looked in the MAME tilemap viewer first of all – the background mountains started around location 0xf0 in the viewer.  It appeared the tiles from location 0xe0 and up were being drawn instead, so I wondered if bit 4 was stuck somewhere (bit 4 being 0×10 in hex which is the difference between 0xf0 and 0xe0).

20190304_080425 20190304_080348

Probing around the tilemap part of the schematics I found the A4 output line on the LS273 at 5A was indeed stuck low even while the input was pulsing.  In fact a multi-meter showed the line was physically tied to ground rather than just logically low, so some kind of internal short.  The LS273 was replaced and backgrounds were correct again.


As most of the sprites were correct I suspected the eproms – there are 3 pairs and a failure of any pair would affect some sprites but not others.  Eprom 16 was indeed bad, and sprites were fixed when I burned a replacement.  Underneath the sticker the reason for the failure was obvious – some kind of physical impact had smashed the die.

20190304_195853 20190304_204408



Namco Galaga 88 arcade pcb repair

Game booted to distorted text.  Although it wasn’t readable I suspected the error related to the custom key chip, a security chip used in these boards.  Swapping the keycus with a known working one enabled the game to boot, confirming the failure.  Luckily the program ROMs can be patched to ignore the keycus completely.


The distorted look applied to all tilemap graphics in the game as well as the text.  A logic probe on the graphics ROMs showed one of the address lines was stuck – that was the reason for the blockiness – repeated pixels because certain addresses could not be accessed.  The tilemap and text is driven by the 123 custom and all signs pointed to that being the cause of the stuck address line.  I swapped it with one taken from a Final Lap board and… no change.  That sucks.  It seems I didn’t check the inputs well enough to that custom as there was a dead input – which in turn caused the stuck output.  Although this custom generates most of the address lines for the tiles LN0, LN1, LN2 come from the CPU board.  This was a physical fault – the pin for LN2 was snapped off inside the connector.  With that patched everything was fine for the main tiles.  The text layer had a little extra fault which was corrosion under the ROM socket.  One of the data lines sometimes did not make good contact between the text ROM at U8 and the 123 custom.

20190209_211231 20190209_211241 20190209_181521 20190209_165343 20190209_181532



Sega Outrun arcade pcb repair

Game was stuck in a reset loop with only colored lines on screen. Logic probe confirmed the main CPU was continually resetting. I initially suspected the RAM as the TMM2063 chips used on this board can often be unreliable. I piggybacked known good RAM over each chip one at a time and although the game still didn’t work, the colored line behavior changed with the RAM at IC130 and IC115 piggybacked. A change was enough to convince me to desolder this RAM and fit sockets and new RAM. Game worked again!

20181216_110012 20181221_081308

With the board out of the cabinet this was also a good time to fit the ‘enhanced’ ROM set –

Some notes on bench-testing Outrun

Outrun is not a JAMMA game of course, so the minimum to bench test is connect +5V and GND to both boards, as well as monitor GND, sync and RGB. Hooking up 12V, -5V or any inputs or sound is not required to get the game to boot.

20181218_084442 20181221_080853


Konami Aliens arcade pcb repair #2

20190218_081053 20190218_075726


Game had bad graphics on the intro and missing title screen.  Mask ROM test indicated rom J13 was bad – and it was.  A 27c400 eprom was used as a replacement (if I remember right that’s actually twice as big as is needed, but I didn’t have any others spare.  Instead I used the trick of writing the same data to upper and lower halves of the ROM so it was correct regardless of the state of the top address line).

20190218_183836 20190218_183848



Sega MegaTech arcade pcb repair

The MegaTech is a pretty rare system, I’m not sure it was even released in the USA.  The hardware is based on the Genesis/Megadrive and there are 8 cartridge slots on the board.  An extra monitor in the cabinet lets the user select between the available games.  Around 60 different cartridges were released which let the operator easily switch games inside the cabinet.

This board though – was absolutely dead – black screen.  The ‘master’ of this board is actually the Z80 CPU that controls the menu and 2nd monitor – the ‘slave’ is the 68000/Z80 combo from the Genesis system.  This BIOS Z80 sits on a little sub-board with a parallel port, but that seems to only be used for coin statistics data, so the Z80 can be plugged directly into the main board to eliminate any problems with the sub-board.


Nothing was obviously wrong with the CPU or the board though – so I used my home-made Arduino in-circuit probe to replace the Z80.  With this I could test the memory and quickly found the 6264 RAM chip was flaky – it mostly worked but would sometimes return random values.  When replaced the memory test was perfect but the game was absolutely still stuck on a black screen.


I moved onto to test the Sony CXD1095 chips – these are just off the shelf port extenders and the BIOS Z80 can access two of them, to handle inputs and drive some outputs.  The inputs all tested good – I could ground out various inputs, and see the result on the Arduino tester.  I could also see the port that detects cartridge insertion working as the value changed as I removed and installed carts.  At least one of the outputs seemed bad at IC24 though – it was attached to a pull-up resistor but the chip was unable to drive it low.  I swapped this chip out with one from a Thunderblade and some progress at last – the BIOS Z80 booted and gave some video output.


However, it refused to detect any games – from examining the MAME source I knew the BIOS Z80 is able to read data from the cartridges – and it uses that data to populate the menu.  The Arduino tester showed the CPU was just reading 0xff for every byte in the cartridge region.  This traced back to the Sega custom 513-5309.  This chip is somewhat documented as it’s used on the Megadrive/Genesis as a bridge between the 68000 and the Z80.  A logic probe showed the chip wasn’t dead, so I examined more with a scope – with 1 probe on an input line and 1 probe on the output line I could see the ROM reads were working on the 68000 side of the bus, but absolutely nothing made it through to the BIOS Z80 side.




A vintage Genesis was sourced as a donor, only the early revisions contained the 513-5309 chip (must say ‘High Definition’ on the front and have a ‘long’ FCC ID number) – the chip was swapped and the rare MegaTech was perfect again.  (The early Genesis has a handful of other parts useful for System 18 repairs also).


20180913_074914 20180915_111400 20180915_111524(0)





Konami GT arcade pcb repair

Game would boot to a corrupt screen then reset.  Comparison to MAME suggested it was trying to draw the ROM check screen, so it was possible the RAM used for the screen itself was bad and the reason for the corruption.


The game has 3 TC5535P-A RAM chips on the video board – I held the 68000 CPU in reset so I could use a logic probe on the RAM without worrying about writes getting in the way.  It was obvious one of the chips had a very weak data output so it was replaced and everything worked.  The TC5535 actually seems to be quite a rare chip now – luckily I had a spare from a Nintendo VS board.








Atari Gauntlet arcade pcb repair & dual boot

    Gauntlet 1 PCB

Initially booted with corrupt sprites – certainly drawing as the wrong width – then subsequent boots showed no sprites at all.


I went through the ROMs and PROMs to reseat everything and a problem was soon obvious – 136037-103 had previously been inserted with the power pin bent outside the socket – a weird fault but when restored everything was 100%.

    Gauntlet 2 PCB

Game played but with corrupted graphics most noticeable on the title screen and test mode. The graphics in Gauntlet are 4 bits per pixel, with each plane stored in a separate ROM. By removing ROMs one at a time it became clear the corruption was on plane 0 only. With the ROM at 1A removed although the title screen had wrong colors there was no more noise or corruption. My initial thought was this ROM had failed – but it tested ok off the board, and a replacement ROM showed the exact same fault. Next to check are the two custom chips next to the ROMs – these are identical and process a pair of planes each. I swapped the two chips but the fault stayed on plane 0 rather than move to plane 2.


I then used a scope on the data pins of the 1A socket and found D7 was noisy whereas D0-D6 were clean (held high by the pullup resistor pack). It seems the ROM at 1C was emitting noise onto the bus even though it wasn’t enabled – with that ROM replaced everything was good.

    Dual Boot

The dual boot process is well documented on the Gauntlet site at ionpool –

In case that site ever goes down the process is quite simple as Gauntlet 1 & 2 are essentially the same board and already share some ROMs. For the ROMs that differ – 4 graphics ROMs, alphanumeric ROM, 4 program ROMs, 2 sound ROMs and the settings eeprom – the idea is you replace each with one that is double the size. Then you put the Gauntlet 1 data in the ‘low’ half of the ROM, and Gauntlet 2 in the ‘upper’ half – now by pulling the top address line either low or high you can force one game or the other. You can install double stacked sockets to achieve this, but I went for the simpler route of just pulling the relevant pins outside the sockets and running patch wire between them.






Atari Centipede arcade pcb repair

The failed AR2 power/amp unit for this cabinet was rebuilt and tested fine but the logic board had also developed a graphics fault.  The test mode gave some clues as to what was going on as the character test only displayed odd numbered characters (A C E G).  This suggested the low bit of whatever selected the character was stuck.  The screen full of A’s was because the space/blank character was stuck as an A also.


I used MAME to clarify the layout of the character ROM – each character is 8×8 pixels in size and each row of 8 bits is stored as a byte, then 8 sequential bytes for the 8 rows.  So 8 bytes a character means 3 address lines (2 to the power 3 is 8), or A0-A2.  That means that if every alternate character in the range was bad, the next highest address line or A3 is the place to look.


The addresses track back from the ROM to a LS86 at E7 – this was removed from the board and tested – and yep, it had failed in exactly 1 bit.  When replaced with a new chip the game was fine.