Anyone who loved arcade games in the mid-80s most likely came across an all-time classic, Capcom’s Commando from 1985. In the game, players control a soldier named Super Joe, who must fight through enemy territory to rescue prisoners of war. The gameplay involves moving vertically upward through a scrolling landscape, shooting enemies and dodging their attacks while collecting power-ups and grenades to aid in the mission. The game is known for its fast-paced action, challenging difficulty, and iconic overhead perspective. Commando was highly influential and set the stage for future games in the run-and-gun genre.
At 11 years old I put a fair bit of my pocket money into the arcade, but it was at home, on my beloved C64, that I did most of the playing. The C64 conversion is particularly iconic for its exceptional soundtrack composed by Rob Hubbard. Renowned for pushing the limits of the C64's SID sound chip, Hubbard's music in Commando stands out with its dynamic and catchy tunes that perfectly complement the game's intense action. The combination of addictive gameplay and Hubbard's groundbreaking music has cemented the C64 version of Commando as a beloved classic in the chronicles of video game history. I had the game on original cassette, and I do remember the 5+ min loading time with the great loading music and fantastic PETSCII arcade graphics.
Now, later in life, I’m fortunate enough to have acquired my own arcade cabinet (a new-build), which is equipped with a Jamma-compatible emulator. This setup also allows me to install and run original PCBs with some additional cabling and trickery (definitely more fun to play the original than the emulator). A few years ago, I treated myself to another favorite game from both the arcade and the C64: Ghosts 'n Goblins, also from Capcom and released the same year. While I initially bought it in working condition, it unfortunately broke down, prompting me to repair it. Although I haven't documented the fun and challenging experience of repairing that PCB, you can see it in action on this page.
While it was difficult to repair the board, I have fond memories of it, so a couple of years later, I decided to take on another challenge when the opportunity arose. I’ve been keeping my eyes open for a Commando PCB, but the ones that have come up on eBay have been a bit pricey, and just “owning” one isn’t as much fun. So when two different sellers listed defective Commando PCBs for sale, I had an idea: if I bought both, to a relatively low price, I could hopefully learn and investigate enough to get them working again. The plan was that where one board failed, the other might still function, allowing me an easier way to figure out what’s wrong. It was a good plan, but it turned out to be far more work than I anticipated :)
The Commando PCB is actually composed of three interconnected boards, each serving a distinct function crucial to the game's operation. The middle board houses the CPUs and the Jamma connector, forming the core of the system where the main processing and game logic occur. This board is essential for controlling the overall operation of the game and interfacing with the arcade cabinet's controls and display. The bottom board is responsible for handling the sprites, which are the moving objects and characters within the game. This board manages the rendering and movement of these sprites, ensuring smooth animation and interaction within the game environment. The top board focuses on the background graphics, including the tiles that form the game's environment. This board ensures that the scrolling backgrounds are rendered correctly as the player moves through the levels.
One of the Commando boards was in significantly worse condition than the other, with several clear issues, particularly with the main CPU and other critical ICs. Anticipating a fair bit of work to get them operational, I decided to start by addressing the cleanliness of both boards. Both were very dirty, with one being notably more so. To begin the restoration process, I cleaned both boards thoroughly using isopropanol. This initial cleaning step was crucial to remove accumulated grime and residue, allowing for a clearer inspection and making subsequent repairs and diagnostics more manageable. Luckily you can get your hands on a detailed 37-page document essential for repair and maintenance. It includes three sheets for the top board, eight sheets for the middle board, and six sheets for the bottom board. These schematics provide crucial diagrams and technical information to diagnose and fix issues, making it a vital resource for anyone working on this classic arcade game.
After cleaning both boards, I decided to power them up to see if there was any sign of life, despite my low expectations given their condition and their status as scrap. Surprisingly, the board in better shape powered up and displayed a screen with static and garbled characters—at least something was happening, which was an encouraging sign of potential functionality. The other board, however, showed no response at all, indicating that it would require further investigation to determine the underlying issues. Given that the game has three boards, I decided to test just the middle board containing the CPU to see if the CPU and program would initialize as expected. I disconnected the top and bottom boards from the game that had at least shown a picture earlier. However, this time, the game didn't boot up at all. After analyzing the schematics, I discovered that the main CPU clock signal is controlled via B15 on the joint connector, which is controlled by the top board. By grounding B15, I was able to get the clock signal through to the CPU as expected. With this adjustment, I successfully got to the screen with garbled graphics using only the middle board. This was a promising first step in the troubleshooting process.
One of the advantages of working with old arcade games is the availability of emulators, and MAME is an invaluable tool in this regard. By running Commando in debug mode, you can set a breakpoint when the main CPU is accessed, allowing you to see what code executes during the CPU bootstrap process. The Z80 CPU always starts from address $0000, so it’s a matter of identifying which ROM corresponds to this initial code. On the board, this is ROM #4 located at 9M. However, examining the photos of the PCBs reveals some complications. Both boards are bootlegs and feature different solutions for the custom chip found in the original Capcom boards. This particular board uses double-stacked ROMs, about which there is little information, but I managed to find some more information on the solution for the other board that brought some clarity to the setup. The custom chip's role is essentially to "decrypt" the opcodes before they are processed by the main CPU. It sits between the CPU data bus and the rest of the system. When the M1 signal from the CPU is high, the data passes through unaltered. When the M1 signal is low, the chip swaps the bits on lines D1-D3 with those on D5-D7, thus decrypting the opcodes. This intricate process is crucial for the game to run correctly, as it ensures the CPU receives the correct instructions from the ROM. I didn't want to start tinkering too much with these ICs before having a clearer understanding of what was going on, so I hooked up my logic analyzer to examine the address and data buses connected to the CPU. The output was inconsistent, which suggested that the ROM containing the initial code might not be functioning properly. With no other option, I decided to take a closer look at the stacked ROMs, starting with the top-mounted one.
The top ROM was simpler to deal with compared to the bottom ROM, which had a soldered socket on top, making access more difficult. Trying to read the top ROM with my MiniPRO confirmed my suspicions—the ROM couldn’t be read reliably. Fortunately, I had a supply of 27128 and 27256 EPROMs, so I burned a new one using the MAME image. When I installed the new ROM, the board sprang to life! Although there were still some issues, I could see the start screen text at the top and bottom, albeit with some graphic bugs. For fun, I plugged in the top board to see if any background graphics appeared. Some background tiles now show up, but clearly not working as expected. By tracing the logic for generating characters, I noticed a stuck pin on the 74LS194 IC at location 4F. I desoldered the broken IC, added a socket, and installed a new 74LS194. This fixed some issues with the character graphics, marking a step forward in the repair process. Progress was being made! Given the issues with the ROM #4 I thought it was worthwile testing all the other ones. Some read OK on the MiniPRO, but several were not and needed replacement. Easy when they're all socketed already. Now the game actually start looking as it should.