In for repair was DoDonPachi Saidaioujou, a Cave shoot-em-up running on a CV1000-D board. This board is one of the recent reproduction bootlegs that’s distinguishable from an original by having gold-plated JAMMA fingers rather than tin-plated.
The board would not boot up at all and a D6 LED would light up.
As per the CV1000 entry at the JAMMArcade.net PCB Encyclopedia, if D6 stays lit up, it indicates a problem with the clock generator located at position X2 on the board. Sure enough, the X2 part on this board is damaged – you can see right into it!
I sourced a replacement part from DigiKey. It is a 32.768 kHz crystal resonator measuring 4.9 mm X 1.8mm . Once the replacement part arrived, I used hot tweezers to remove the old crystal and then soldered the new one in.
That’s all this board needed – with the new crystal in place, the game booted up and functioned perfectly. A successful repair!
In for repair was Muchi Muchi Pork, a Cave shoot-em-up running on a CV1000-B board. The game had visual corruption showing on one of the enemies in the game:
Note that the art asset viewer is hidden in this game. Flip Switch S2 on the board to the left, and hold down the Shoot and Bomb buttons while powering on the board. Once the game boots, keep both buttons held and enter the Service Menu. Additional hidden options – including “TGA TEST” for the art asset viewer – should now appear in the Service Menu list.
Cave CV1000 boards used substandard flash storage and are rather notorious for issues with corrupt assets like this. There is further information on these failures at the CV1000 entry at the JAMMArcade.net PCB Encyclopedia.
Previously, repairing this kind of issue would require desoldering the affected flash chip from the PCB, dumping it, modifying the dump to work repaired data in around the failed block of flash, reprogramming the flash chip, and finally resoldering it back to board.
Thankfully, these days buffi has conducted extensive research and produced tools for reprogramming the CV1000 CPU and Art flash chips over JTAG – no soldering required. If the flash fault has occurred in the Art flash chip (U2), Alamone has also produced scripts that automate the difficult step of mapping good data in around the failed flash blocks. With all of these tools in hand, repairing this sort of fault without soldering over JTAG is fairly straightforward.
Note that with CV1000 the Art flash (U2) and CPU flash (U4) are accessible over JTAG while the Sound flash (U23 & U24) are not. Repairing faulty flash issues with the Sound flash thus still requires desoldering and resoldering.
There are two kinds of USB JTAG adapters that can be used for communicating with a CV1000 board – an Altera USB Blaster or a Tigard. I went with a Tigard because it communicates with the CV1000 substantially faster than the Altera.
I’ll break down the steps I used to access this CV1000 board over JTAG.
Next, I downloaded Buffi’s JTAG Python scripts and Alamone’s U2 Compare script to the R-Pi using the web browser on the Pi. I also downloaded a clean MAME ROM of the Muchi Muchi Pork game.
Next, as per Buffi’s instructions, I setup the JTAG libraries on the R-Pi using the Terminal commands. If you use the Tigard JTAG adapter, there is an additional step that’s missing from his documentation. Edit the K9F1G08U0M_JTAG.py file, and on Line 186, change the False to True.
sudo nano K9F1G08U0M_JTAG.py
Next, I connected the Tigard JTAG adpater to the CV1000 board, following Buffi’s pinouts in his instructions. The TRST pin should stay disconnected for now, but it will be connected after booting up the board.
As per Buffi’s instructions, the CV1000 needs to be started up in a special ASE reset hold mode. I flipped Switch S1 so the switch isn’t between the white lines. I connected a DuPont female-to-female jumper wire between Pin 14 (GND) and Pin 3 (TRST). I turned the power on and confirmed that the CV1000 turned on a green light and that the game did not boot up. Finally, I disconnected the Ground jumper wire and connected the TRST pin from the JTAG programmer.
Now, with the software environment ready, the JTAG USB connected and with the CV1000 booted up into the correct mode, I would issue the following commands on the R-Pi to check the JTAG connection to the flash chips:
Information about the U4 CPU flash chip was displayed, so the JTAG was communicating with the R-Pi properly.
This board didn’t have any obvious problems with the U4 CPU flash, but I went ahead and dumped it anyway so that I could check it for corruption.
readmem 0 0x200000 u4.bin
Note: if this was a CV1000-D, I would have typed 0x400000 instead of 0x200000.
After a few minutes, the U4 flash was dumped. Uploading it to Hamster’s Online ROM Identification site using the R-Pi’s browser confirmed that it was a 100% match for the MAME dump of the game.
Now it was time for the real culprit – dumping the U2 Art flash. Rather than the jtag prompt, type “quit” to exit, and then use this command:
With the Tigard adapter, this operation took a few hours to complete. I understand that with the Altera adapter, it can take 3 days.
With a dump of the faulty Art flash now in hand, Alamone’s U2 Compare tool can compare it against a good dump of the art assets and generate patches around the faulty flash. I issued the following command:
sudo python3 u2compare.py u2 u2bad.bin u2fixed.bin
Here, “u2” is the filename of the good Art flash dump from MAME, “u2bad.bin” is the faulty Art flash dump from the board, and “u2fixed.bin” will be the repaired dump.
After a moment, U2 Compare finished its operations. Two bad blocks in the dump were detected, and four patch block files were generated to address them.
The next step is to write the four patch block files back to the Art flash on the CV1000. Buffi recommends backing up the factory Bad Block Table on the flash before any CV1000 flash writing operations, so I went ahead and did that for the Art flash with the following command:
Now it was time to disconnect JTAG and test the board. I powered down the CV1000, disconnected the JTAG wires, moved the S1 Switch back to the stock position and powered up. After the game booted, I entered the special service menu and confirmed that the corruption from before was now fixed.
For good measure, I also played through the entire game and confirmed that there was no asset corruption. The game is fixed!
Hello everyone, this time I have a SNK Neo-Geo MVS game cartridge on my desk. It has glitches with some of the graphics.
MVS cartridges consist of 2 boards – the PROG board and the CHA Board.
This particular PROG Board holds 16-bit P ROMs and V ROMs.
P ROMs are Program ROMs. Some other Neo-Geo games use 8-bit parts instead for the P ROMs labeled either SP1/2 or EP1/2.
V ROMs are audio ROMs which holds ADPCM audio samples.
Since this game boots up and runs, and the sound is perfect, we don’t need to examine the PROG board at the moment.
Let’s take a look at CHA board. CHA Boards hold C ROMs, an S ROMs and a M ROM.
M ROM is a 8-bit ROM containing the Z80 Sound CPU program and data. Without it, you don’t get any sound.
S ROMs are Graphics ROMs containing tiles for the “fix” layer. The fix layer is a non-scrollable, tile-based layer with transparency which has the highest priority on the display (it always overlaps sprites). It is most often used to display text or HUDs like scores and health bars.
And finally we have C ROMs. C ROMs are 16 bit sprite graphics ROMs organized in pairs, each containing half of the bitplanes for sprite tiles.
Let’s see the fault with this particular cart before proceeding further. This white square is supposed to display a video:
Where’s the background???
There’s supposed to be two Dragons showing here instead of glitches.
Also you can see a video of the graphics corruption here:
Okay, since the graphics issues are with sprite tiles, we know the problem is with the CHA board, and we know that there’s something wrong with the C ROMs. But which ones?
For this situation, let’s consult the MAME ROMs. MAME’s dump of this game is “doubledr.zip”. Here are the contents – there’s one file for each ROM chip on both boards.
What I will do now is simulate the same error I’m seeing with my physical cart on MAME by corrupting each C ROM file one by one.
Normally, MAME does a hash check on each file when booting up a game – if the hashes don’t match for a file, it won’t start the game. But if you launch MAME from a command prompt, it only warns you and it will start the game.
I’ll start with corrupting the C8 ROM since it is 1MB in size, and thus equivalent to a 27C800 EPROM (of which I have plenty).
That’s looks like it – when MAME runs with a corrupt C8 then the same sprites look glitched as on my cart. The glitches look different glitches but the same sprites are affected.
Let’s desolder the C8 ROM from the board:
The MAME file for this part is 1MB in size. As mentioned above, the EPROM equivalent is a 27C800. Be careful when replacing a mask ROM part with an EPROM part – don’t always do this by size, because some ROMs like M1/S1 use different pinouts.
Here is the CHA board with a socket and programmed 27C800 installed:
Time to power up and give it a shot!
Well, the graphics are looking better than before, but they’re still bad. Here’s the video:
Next, I simulate a corrupt C7 ROM in MAME in the same manner and see that the same sprites glitch. So I go ahead and change out the C7 mask ROM for a 27C800 EPROM on the board too:
Now this is the result:
Everything fixed! Here’s the video:
It turns out that you cannot close up the cartridge shell when using sockets. Therefore, I desolder the sockets out and solder in the replacement EPROMs without sockets.
Hello everyone, this time I have a Konami Asterix board that I got from the Arcade Museum forums. I bought it as non-working “error with 2 chips” at an affordable price.
This is the board:
I immediately attached it to my JAMMA Test Rig and powered it up.
Indeed, we see 2 defective chips on the board’s ROM Check screen – 2F and 5F.
When examining the board, we see that 2F is a RAM chip while 5F is a ROM chip.
The 5F EPROM (TMS27C512) is already socketed, so let’s dump it and compare it with MAME via the ROMIdent site.
The ROM looks fine and matches what it should be. For good measure though, I’ll rewrite the dump back to the EPROM.
Then, while I’m at it, I’ll write the MAME equivalent dump file 068_a05.5f to another EPROM (W27C512) that I’m sure is good, so that we can try both.
First, I’ll put the old ROM back in and try it out.
Let me give you some information if you try a similar experiment. With some Konami boards, if you change ROM chips, the system might not detect it. For example, when switching from a 2P ROM to 4P ROM, or switching to a different language ROM.
If this occurs, hold down the TEST SW button while powering on the board. You should see an EEPROM Initialization message.
After the EEPROM reinitializes, it goes into the normal boot routine. Let’s see if 5F is fixed.
Not yet! Let’s try the new EPROM I wrote in case the old part is faulty.
It’s still not fixed. For now, let’s leave all this aside and deal with the RAM. Maybe problematic RAM is also causing problems accessing the ROM.
I carefully remove the old RAM by desoldering it from the board.
I’m out of suitable sockets for that pinout, so I cut down a large socket. It’s not fantastic but it does work!
The part number of the RAM that came out of the board is MB8416A-15L-SK. I have a similar part that I can put in its place – MB8416A-12L-SK. The 12 means 12ns, i.e. shorter access time, i.e. faster RAM.
First, lets test the old RAM out of circuit with my EPROM programmer.
This RAM is a 6116 series equivalent. There are various cross reference sites to see equivalents. Or you can compare two datasheets and look; if you do this, pay attention to both the pinout and memory layout.
Test Result: Normal. The only time I regret that something is intact is when I’m repairing something and I suspect that the component is faulty. I wish it was faulty so I could just replace it and have it work!
Anyway, let’s install the new RAM into the socket and boot up the game board. Sometimes out of circuit test results can be inconsistent…
Hmmm, the 2F and 5F chips are still marked BAD so things are complicated. Apparently neither the ROM or the RAM is the problem. But somehow these two can’t be accessed correctly by the CPU. When examining the board for physical damage, I didn’t see any broken wires on the board. I didn’t see any cold solder.
Let’s keep digging. At this stage of the repair, I take out my Logic Probe and start checking signals.
I see a High (No Pulse) signal on the 18th pin of the RAM. This is the Chip Enable pin. The datasheet shows a line over the label for this pin, showing that its Active Low. Thus, the RAM is not being enabled.
When I check the ROM, I see a LOW signal (No Pulse) on the Pin 20. This pin is also the Chip Enable pin for the ROM. Just like the RAM, the pin is labeled Active Low on the datasheet so the ROM is being enabled.
When I measure with a multimeter set to Continuity Test where the Chip Enable line of the RAM goes, I see that it goes to a PAL chip.
PALs are custom chips. If this PAL is faulty and has no dump, the only solution is to source a PAL from a donor board. If it has a dump (this one does), write the dump to a compatible GAL chip and use it. [Editor Note: The PLD Archive website is an excellent source for PAL dumps.]
I don’t have a GAL but I have a better option – a working Asterix board! Having a working board to compare against is very useful when working on boards without schematics like Asterix.
With the Logic Probe, I test the pins of the working and non-working board and compare the results. I do this test by powering each board off and on repeatedly through the startup diagnostic checks.
PAL TEST
H -> High L -> Low P -> Pulse
Not Working BoardWorking Board
Quite different. There is no pulse on several lines on the non-functional board.
I’m confident that this PAL is the problem, and since I don’t have any GAL, I removed the PAL from the working board. You know the rule that if it works, don’t touch it? Arcade boards don’t have this rule 😀
Here is the functional PAL, transferred from the working board to the non-worked board and socketed:
Time to power up!
PFFFFFFFFF. Just when I’m about to give up, something catches my eye. Did you see it? Look a little closer..
Yeah, right there… The IC with the F emblem. It’s a flip-flop circuit. But the important thing here is the brand. Fujitsu ICs are the most prone to failure. I take my Logic Probe in my hand and start probing from the top right pin on the chip (VCC). Let’s power up the board again…
Whoa! Before I can understand what the probe is saying, I hear horse footsteps…
I don’t know what happened, but the board works now. I set the board aside for two days, and when I tried it again, it works fine. I have no idea if probing the VCC pin of that Fujitsu IC triggered something, but it works. I did not change out that part yet because it is working for now.
Hello everyone, this won’t be much of a repair article but stay with me. This game is Konami’s Boot Camp. Actually this name is the name published in America – in Europe we know this game as Combat School. It is one of my favorite games. I thought it was the same between regions and bought the USA version, but there was a difference – the American version is played with a trackball, not a joystick. I will convert my board to play with a joystick at some point.
Here is the board I received:
The board was sold to me in “working” condition, but when it arrived I encountered a problem. At first, the RAM & ROM Startup Tests pass successfully: and the title screen appears as it should:
But along the top edges of the title logo and inside the game itself, there is random pixel corruption everywhere. The circled pixels on the flagpole shouldn’t be there.
Then, when positioning the board to start investigating the problem, I realized that a part of the board is very fragile because when I touched it, it fell off!
If you ask what this IC “UPA1452H” is for, I will quote you directly from the datasheet:
[i]“µPA1453 is a PNP silicon epitaxial Power Transistor Array built
in 4 circuits designed to drive solenoids, relays, lamps and the
like.”[/i]
I think this must be a component on this board that drives the trackball. Obviously this is a problem and I wanted to solder the IC back onto the board, but since the legs of the IC snapped off they cannot be soldered properly. So I used a header pin as a dirty and quick solution.
NOTE: Of course it won’t stay ugly like this. As I said at the beginning of the article, I will convert this board to a joystick version later on – when I do, this component will be removed in the conversion process.
After reinstalling that IC, now everything functions normally.
