A lot of boards are awaiting on the “to be repaired” stash, today the random pick is one of my favourite arcade system ever … an SNK MVS board! So i moved it from the stash to my bench for a repair. A clean MV2 dual slot board :
The usual visual inspection, reveals the BIOS IC (on the red square) is missing, the battery seems to be in good condition and no damage has been done due to its acid leakage.
The overall condition is good enough to perform a smoke test, so i plugged in the JAMMA harness and powered up my supergun, finger crossed and i’m been greeted with this error:
A video RAM error is a common issue on this hardware, the error address is not zero boundary, so the culprit should be a damaged video ram chip. The self test program is expecting a 5555 hex value (101010101010101 binary pattern) but the lower half memory chip probably reply with wrong and garbage data, as you can see on the READ lower half value (hex FF instead of 55) and the random characters on the screen.
So i’m going to replace it. On my spare parts i found a 32Kb SHARP LH52B256 a little bit faster than the original TOSHIBA ic, 70ns instead of 85ns, but it should do the job in the same way, it’s the one in the yellow box below:
At this time i decided to give the board a try and i powered it up again, no more garbage on the screen, but there are still strange video errors (picture missing sorry) tipically due to a problem with NeoGeo FAST video RAM. The Sony CXK5814 ICs, a 6116 2Kb standard compatible static RAM, over the ages are very prone to failure, so i replaced both and fitting the proper ic socket, you can see them in the light blue box below:
I replaced the FAST video RAM chips and powered up the board again … yeah board fixed!
Now it’s time to do some deeper testings … 🙂
The board runs fine, the I/O controls, the video and audio sections now are fully working. After the “testings”, i made a minor fix to prevent further damage due to battery leakage, so i removed the original Ni-Mh battery and the 470ohm resistor to deactivate the charging circuit:
… and fitted a CR2032 battery socket on the rear side for easy swapping and maintenance, once the board will be closed with its metallic case.
Just taken a random pick from my “to be repaired” stash, an original TAITO B-SYSTEM arcade board.
The sticker il no more readable, but the eproms labels are marked B93. According on the lists found over the internet this should be a RAMBO 3 board.
The usual visual inspection don’t reveal anything strange, the board is good condition so i’m ready for the smoke test. Jamma harness connected and power feeded, finger crossed and …
I’m greeted with this amazing “hello kitty-ish” pink screen! I think John Rambo shouldn’t be proud of! So before i’ll found him in front of my door knocking and armed, i must hurry and fix the board as soon as possible. 🙂
I powered off the board and i checked if some ICs were getting hot, but everything seems to be ok, but we know for sure that almost one “guy” shouldn’t do the right job on the board. Now i’m ready for a second run and powered on the board constantly checking it. The board seem stone dead, and in this condition the right thing is starting troubleshooting the main CPU looking for good control signals, time passes and no signs of life come from the board. I try to feed a credit to the board and surprisingly i was greeted with the right sound effect! This is a good news so probably the board is playing blind, i checked the dip switches and i tried to activate the attact demo sound, i did a power cycle of the board, the usual pink screen came out but now music and sound effetcs seems to be played in the right way.
So the issue must involve the graphic section of the board. My one cent bet is for the palette RAM, so i put my finger over it, it’s marked IC41 and it is a 2Kb 6116 compatible SRAM, the one with the yellow border below:
Its data and address lines are directly connected to the TAITO Custom IC marked TC0260DAR, the one light blue bordered, the palette generator chip i think, unfortunately no information neither schematics or pinout can be found on the net about this “guy”.
By the way according to the technical specifications the palette RAM on a B-SYSTEM board shoud be 8Kb, a 6264 standard SRAM, but on Rambo 3 board only a 2Kb palette RAM is present, allowing this way a less color depth.
Here’s a brief summary taken from wikipedia:
RAM: 68000 main RAM: 32 KB 68000 video RAM: 46 KB (8 KB palette, 36 KB tilemaps, 2 KB scrolling) Video resolution: 320×224 to 512×256 pixels Color palette depth: 4096 (12-bit RGB), or 32,768 (15-bit RGB)
Looking at this picture we can see the extra unused pins on the left of the palette RAM @IC41 allowing the fitting of a 8Kb palette SRAM as expected by the “standard” base design.
as we can see, according to the MAME source, 8Kb for the palette RAM at range (0xa00000, 0xa01fff) are addressed, exactly 0x1fff hex bytes or 8192 bytes. Maybe should be something wrong here … it needs further investigations.
… but let’s take a step backward and bring the focus back to our not working board and its issue.
Probing the palette RAM address lines with the scope reveals they seems to be in good working order and an apparent regular activity seems to be present, also the control signals seems to be in good shape, but when i checked the data signals i think that something wrong were going on, too poor activity for a palette RAM.
This suspect is enough for me, and i start to replace it, i removed the old ram, i tried my best for a neat job …
… and fitted the proper IC socket.
before proceding, i tested the old RAM on the IC tester, and as you can see it was damaged! The RAM data bus miss the test … Yeah!
I replaced the palette RAM, and fed power to the board again, and …
GOTCHA! It worked! So i could proceed fixing minor issues over the PCB as these damaged, loosen or totally missed capacitors, one 1000uF cap on the 12v rail in the audio section:
and two 220uF caps like this …
Both replaced with their equivalent ones in a bloody-red color! Much better!
I think also John Rambo should be proud of them … and now he’s ready to kill all the enemies!
I’ve got this GOLDEN AXE PCB a SEGA System16b board on the bench from a friend of mine, Daniele, for a repair. The board boot fine, the game starts in the right way, but there is no audio at all.
This should be a quick fix, i think. This is the picture of the board :
The PCB is in very good conditions and no scratches were found on the solder side. So it’s the time to get hands dirty and take a deeper look at the audio section of the board.
First of all i noticed the C18 cap is missing, but according to the System16b schematics i found on the net, the missing cap shouldn’t be involved in the issue, the board il totally silent.
We can look at the missing cap on the red circle, this picture is taken from the sega System16b schematics:
… and this one is taken from the IC datasheet:
For a first quick and dirty test of the audio power amp, a Fujitsu-MB3735, i used an old school method and an absolute high-tech probe … a finger! : )
Adding some interference and extra capacitance the amp should oscillate abnormally and should reply with the classic “hum” noise. This will tell us that the amp may do it’s job, and it seems working.
So we can take a deeper look at the audio chain of the board:
So we can go backward through the audio circuit in the preamp section a quad op-amp marked NEC uPC804C, it’s an equivalent of a better known TL084. Probing it with the scope i found that it was totally silent both inputs and outputs. The inputs are feeded by a Yamaha YM3012 DAC, a digital analog converter, obviusly all the output stages were silent but there is an apparently activity on its inputs. The serial data input pattern looked at the scope seem to be too regular, it should change in some way when differents sounds were played. The input pins of the DAC are connected to the output pins of the FM sound generator chip, a Yamaha YM2151. They are a classic audio ICs tandem, found on several arcade boards.
Also the NEC uPD7751 ADPCM Decoder was silent too …
My suspect is that the CPU in some way should misdriving the sound generators ICs. Before probing around address and data lines on the PCB, we can notice that on the SEGA System16b boards the audio CPU, a classic Zilog Z80, is mounted on a socket so we can easily test if the culprit relies on it by simply swapping it. Using a good Z80 didn’t solve the audio issue, and testing the mounted Z80 reveals it was good, so we need further investigations.
It’s time to take a look at the CPU signals, the clock signal was good, CPU control signals (RESET, HALT, WAIT, …) seemed to be healty, system control signals reveals the CPU is stucked in a READ state no WRITE activity on the RAM, this should be strange in a good working mode. So i started poking with the scope over the address and data lines, it reveals a lot of activity and the displayed patterns seemed to be the usual ones.
But when pinned the probe on the D3 line …
… The yellow pattern is a good D0 line, the green pattern is (inverted for a better reading) the D3 line and it is stuck high. Checking and beeping around the D3 signal for continuity traces testing between CPU, 6116 SRAM, an the FM chip reveals they were all ok. The test points are the ones with the red dot on the upper image of the audio section.
So only few IC remain to test on the shared data bus, the EPROMs. They are placed on a daughter board attached to the mainboard with four connectors. I started from the Z80 sound EPROM a standard 27c256 marked EPR12390, according to the datasheet the D3 signal should be on PIN 15.
The digital multimeter reported no continuity between CPU and EPROM on D3, maybe they can be wired in a different way so i check D3 on the CPU against all the pins of the EPROM data bus, but no audible beep can be heard. I checked the whole data bus and it was ok and only D3 was missing. So this should be the culprit, a broken trace, maybe on the connector, between EPROM and CPU data bus on D3 signal.
I pulled out the EPROM for further investingation and i spotted this:
… so i lifted the pin, reseated the EPROM on the socket and ready for the “smoke test” … and it worked! I was greeted with the usual Golden Axe audio effects and voices, and the well known music theme.
The damaged pin prevent the CPU bootstrapping and executing the right program code, probably leaving it in a endless loop of trash bits with wrong data.
It’s time to replace the missing C18 cap to completely fix the board. Despite of the lenght of this post, it was a few minutes easy fix.
Now, Daniele should be happy! : )