21st February 2022
Continuing on with the TMNT repair, powering on with a good PSU shows the Z80 is active but no sound plays. Or so I initially thought. The
in-game attract mode sound plays! If I start a game there's sound but no title theme music. So we still have a fault in the sound section
btw, I forgot to mention yesterday, before replacing the bad 74LS04 at D8, I could get the Z80 to become active by removing the RAM next to
the Z80. The Z80 wasn't running code obviously, but all the pins were active and it was waiting for something. Yeah, probably waiting for me
to fix it LOL! Anyway I just thought that was a little bit strange. It looks like because the YM2151 was not running due to the missing
clock, the YM brought down the whole sound system including the Z80!
Anyway, this is what the 74LS04 pin 8 and YM2151 clock looks like now. It's about the same as the Z80 clock was before changing out the LS04,
just not as wiggly at the bottom. So yeah, just remember wiggles are bad.
Checking the MAME tmnt source code shows that the chip responsible for playing the title theme is the uPD7759. Referring to the VOICE
schematic page posted yesterday....
and upper left quarter of the board....
The uPD7759 is located at D16. The 640kHz clock (the little square blue thing just above the uPD7759) is present on pin 23. Reset is on pin
19 which comes from a 74LS74 at E10 pin 5 and that is also present and working.
To try to speed this up a bit, rather than randomly checking chips in this area let's try to cheat and have a quick look at every chip on
the VOICE schematic page, make a list and see if any are Fujitsu chips. Then we will have a fixed target to aim at ;-)
Note: The entire left section of the VOICE schematic can be ignored because that's for use with 32 pin EPROMs. This game uses a single 40
pin MASK ROM in the same location.
4069 at F8 (not Fujitsu)
74LS74 at E10, H9 (Fujitsu)
74LS161 at D9 (Fujitsu)
74LS393 at C7, D7, E7 (all Fujitsu)
74LS32 at G9. Hmmm no chip at G9! But there's a 32 at F9 so that must be it!
74LS04 at D8 (already replaced so must be good)
74LS273 at F15, B16 (not Fujitsu)
4Mbit MASK ROM at D5 (Fujitsu)
74LS166 at E7, E8 (Fujitsu)
1Mbit MASK ROM at D18 (Fujitsu)
YM3014 at D10 (not Fujitsu)
OK, so looking at the MAME source code shows exactly which ROM contains the title song....
MAME tmnt.cpp source
ROM_REGION( 0x80000, "title", 0 ) /* 512k for the title music sample */
ROM_LOAD( "963a25.d5", 0x00000, 0x80000, CRC(fca078c7) SHA1(3e1124d72c9db4cb11d8de6c44b7aeca967f44e1) )
This means I can ignore the other ROM at D18. Let's assume that the ROM at D5 is good. I can also ignore all non-Fujitsu chips.
Starting in the top left corner of the schematic, the 74LS74 at E10 has active outputs on pins 8 and 9. Pin 9 is tied to CK input pin 2 of
the 74LS161 at D9. Output pin 15 of the LS161 is active and tied to pin 13 of the LS04 at D8 and the output pin 12 is active and must be
good since we already changed that chip. There's another active output from the LS161 on pin 11, tied to pin 1 of a 74LS32 at G9. The output
is pin 3 and there's an active signal there too so the LS32 is also working. The 74LS74 at H9 is tied into the system reset signal on pin 1.
Input pin 2 is tied to the Z80 databus D2 and is active. Input pin 3 is high but toggles low briefly at the title theme intro screen. Output
pin 6 is high but when pin 3 briefly toggles low, at the same time output pin 6 goes low and stays there for a while. This is obviously the
same period when the title theme is supposed to play because after about 15 seconds pin 6 goes back to high. This means the 74LS74 at H9
is also working.
So I can cross off D8, D9, G9, H9 and E10 as they all appear to be working.
That leaves the 3x 74LS393's and the 2x 74LS166's. Hmmm ok so this is getting very do-able now :-)
Let's look at the 74LS393 datasheet to see how it works....
This chip is a Dual 4-bit Decade and Binary Counter. 'Dual' meaning there are 2 separate circuits in the chip. The datasheet truth table
shows COUNT and 4 outputs. This doesn't match with the chip because the chip has input pins 1A and 2A, and also two CLR pins. On all 3x 393's the CLR
pins are tied together so no need to worry about those. From previous checking we already know that this CLR signal comes from the 74LS74 at
H9 pin 6 and is low when active (when the title theme plays). The 1A and 2A pins appear to be the COUNT signal shown on the truth table. I'm
not even sure I know how to check the count signal but it actually doesn't matter. The pin 1 input (1A) comes from the LS32 at G9 pin 3
which is working. The other 1A and 2A inputs come from these same chips fed from the outputs and chip E7 only uses 1A. The schematic shows
that the outputs from the 393's connect to the address bus A0-A17 (18 address bits total) on the ROM at D5 so these chips are selecting the
ROM address. Two of the outputs from C7 and D7 also connect back to another LS393 input. The inputs on all 3x 393's (1A, 2A) are active. It
appears E7 is the final output which has five unused output pins and three used pins. Two of the used pins are tied to the ROM address lines
(A16, A17) and the remaining used output connects to the LS32 at G9 and both 74LS166's. The 74LS393 output pins for C7 and D7 (2x pins 3, 4,
5, 6, 8, 9, 10, 11) are all active. The 74LS393 at E7 uses only output pins 3, 4 and 5 (the others are no-connect). Pin 3 has no signal at
all (not high, not low), pins 4 and 5 are static lows. I piggybacked a working 74LS393 over the top of E7 and now pin 3 and 4 are active
when the title theme is supposed to play, but I still can't hear the theme tune playing. I pulled and replaced the 393 anyway as it looks to
I tested the old 393 in my chip tester and it fails. The display shows pin 3 is low but a high was expected....
Moving onto the 166's, let's first have a look at the datasheet for this chip....
This chip is a Parallel-Load 8-bit Shift Register. There's only 1 output (pin 13). The inputs (pins 2, 3, 4, 5 10,11, 12, 13, datasheet labels
A, B, C, D, E, F, G, H) are tied to the ROM databus and are all active. The other inputs are tied to existing signals I've previously checked. The
output pin 13 on the 74LS166 at E7 goes to the other 74LS166 at E8 into pin 1 (SERIAL). At the point before and during the title music playing, pin
13 of E7 looks like this....
Similarly pin 13 of E8 looks like this....
This is where a CRO can be over-rated because I have no idea what it's supposed to look like. To me it looks like both chips are working
since the waveform changes when the theme song starts to play and goes back to the same as before when the theme stops and the waveform is
not complete garbage. But E8 seems to have less activity so maybe it's suspect. Additionally the signals sound and look ok with my logic
probe. I piggybacked a working LS166 over E7 and it didn't affect anything. I piggybacked a working chip over E8 and I can hear the theme
song playing! It's really scratchy and rough but I can definitely identify it as the TMNT theme song. So I suppose E8 is bad. I changed it
for a working chip....
I tested the old 166 in my chip tester and it fails. The display shows pin 13 is low but a high was expected....
After changing the chip, I powered on expecting the theme tune to play perfectly but it's exactly the same as when I piggybacked the LS166
on top of the bad chip! Looks like we have a fault further down the line, maybe in the analog opamp section.
I'm kind of running out of time and patience now. I pulled a bunch of the remaining Fujitsu chips and some others in this same area... the
YM3014, the other two Fujitsu 74LS393's, the other Fujitsu 74LS166 and the LM358 at C10. I tested the LM358 and YM3014 on a different board
and they are fine. I tested the pulled logic chips in my chip tester and they pass. I pulled and read the ROM at D5 and it matches MAME
archives. Just to be sure I replaced it with an EPROM but that didn't make any difference. I replaced the pulled Fujitsu chips with good
chips (never put Fujitsu chips back on a board even if they test good!!) and put everything back and it may be fixed. I'm not sure. The
theme tune plays fine with the volume on a normal level. But when turned up to full volume it sounds like it's clipping. But this is
definitely an improvement so at least one of the chips I just replaced was marginal but not showing up on the CRO or logic probe or chip
tester! It sounds pretty good now as long as the volume is not set at maximum. In reality no one is going to put the volume up full anyway
so it's probably good enough to call it fixed ;-)
There are some opamps further down the line (2x LM324 and another LM358) but if they were bad then all the sounds would be bad and it's only
the theme tune that sounds clipped at full volume. I suspect it's not right but I don't have another board to compare against. It could be
some caps I suppose. The owner has another board so I've asked him to check it and get back to me. It sounds ok at normal volume so even if
it's not correct it probably doesn't matter.
Update 22nd Feb: The owner said at full volume the theme tune is distorted on his other working board exactly like I described. So this seems
to be a common issue with TMNT! So the sound issue is 100% fixed :-)
It's time to go back and have a look at that red 'Scene 1' screen.
I figured this fault is probably in the color section of the schematic....
The color RAM at F22 and F23 must be good otherwise there would be huge color issues. Anyway, the color RAM is tested at boot-up and passes
so must be ok. If I narrow it down to just Fujitsu chips, there's not many... the 4x 74LS07 at D23, E20, D20 and D22, 3x 74LS157 at D25,
E25, G25 and the 74LS32 at H21. I checked the 07's and 157's with the logic probe (all ok) and also piggybacked chips over the top and there
was no change on screen at the 'Scene 1' screen. I checked the outputs on the 74LS32 and pin 8 is a static high. The input pins 9 and 10 are
active so this chip is bad. I piggybacked a good chip on top and now the 'Scene 1' screen is black like it should be. I pulled and replaced
Strangely the known bad Fujitsu 74LS32 tests ok in my chip tester and also in my EPROM programmer logic test function.
The final minor issue is a broken cap. This doesn't actually do anything and before starting the repair I just snapped it off for the entire
repair and everything was fine. If you see this kind of thing on a board, DON'T just push it back on. It can cause a short and on a 12V cap
that would be very bad ;-)
This cap is C20 shown on the SND schematic page near the main power AMP at location J1. It just sits between
12V and ground. I've replaced it with a new one. I may change out the remaining caps later if necessary. One last thing is there's some sort
of, erm, white crap on the OBJ ROMs. Not sure why, but looks like some TMNT fan boy got a bit too excited and shot his load on there LOL!
It's all cleaned up now :-)
Here's the final 'summary shot of shame'. Don't look too closely, this can give you nightmares for days! ;-)
For now all the faults are fixed so that's the end of this TMNT repair log. I may change out the remaining Fujitsu logic chips just to make
sure it doesn't fail again. But that will be done another day. I'll ask the owner what he wants to do about that. The relentless summer heat
is erm, relentless (hehe!) so now it's time to relax with a lemon, lime and bitters and recover for a while!
20th February 2022
A local friend asked me to look at a Teenage Mutant Ninja Turtles (TMNT) board that he picked up as a spare some time ago. It was working with a minor graphics fault and there was no sound at all.
I forgot to take a pic of the board before I started so here's a 'stock' picture hehe! The board I have will be shown a bit later once the
repair starts. Anyway it's just a common TMNT board, nothing unusual.
The particular board I have is a very nice example because there's no corrosion damage and no cowboys have butchered the crap out of it. No one has
touched it before, which is quite rare these days. There were no boot-up errors so most of the board seems to be fine. This is very unusual
because these boards have dozens of Fujitsu logic chips and there has to be several of them dead or failing. That's almost a guarantee!
I first flicked on the test DIP switch to check the MASK ROM test. I powered on and the game came up as usual... no test mode!
I started probing around the DIP switch area then suddenly I got this.... (!)
Whoops! Something just failed and now there's only a bunch of wiggly crap on screen LOL!
Looks like there's no sync signal. Fortunately the full schematics are available. Even better I own the original paper manual with the
For this log I will be using the good-enough poorly scanned schematics that are available online. But don't worry, I will fix this problem later ;-)
I had a quick look to see where the sync signal is coming
The first image shows the sync signal on JAMMA pin 13 and it comes from a signal called 'SYNC' with page reference IOE3. The 2nd page shows
part of the IO page and the SYNC signal comes out of pin 5 of a 74LS244 at location D27. Looking at the board, this is our unfriendly
Fujitsu branded logic chip. Probing the sync input (pin 15) shows a normal sync signal and probing the output (pin 5) shows a static high so
the sync is not coming out. Additionally, the 4-position DIP switch is also connected to this chip and DIP switch #3 is the test mode switch
so that explains why the test mode doesn't work. I replaced the 74LS244 with a working chip and now the board is back to normal, or at least
as normal as a partially working TMNT board can be heh! I tested the bad 74LS244 in my chip tester and it shows that the chip is partially
working but pins 5 and 16 are stuck high.... pin 5 is the sync output and pin 16 is the output for input pin 4 which is the signal coming
from DIPSW3 switch #3 :-)
I flicked the test DIP switch on, powered the board on and got this....
OK, so now the board is booted, this shows the minor graphical glitches that the owner mentioned and the test mode says ROMs K6, H6 and K27
are bad. They might actually not be bad. All this means is the board is not getting back the right data when it calculates the checksum. I
looked at the schems and these ROMs are listed on the VRAM and OBJ pages....
Let's look at K27 first. This ROM has a long indented line across the length of the ROM. That's a sign that it's a Fujitsu ROM. These ROMs
are also failing a lot nowadays, especially on 90's Sega boards. The schematic shows K27 is connected to the custom chip 052109 and the MASK
ROM at H27 and nothing else of significance (CN5 is the expansion connector which is not used). I beeped out all the pins of K27 to H27 and
to the custom chip and everything is connected. I also checked every pin on all the large square custom chips to make sure all of them were
properly soldered down and they were all good. The only option remaining is to pull the ROM and read it in an EPROM programmer to see if it
matches the known good archives from MAME. The ROM doesn't match so I replaced it with a AM27C400 EPROM....
Yup! That fixed the error on K27. Now there are only two bad ROMs remaining. I beeped out the connections on the ROMs at H6 and K6 and
checked for loose legs on the custom chips and everything was connected as per the schematic. I pulled and read these ROMs but they tested
ok. This is not surprising because these other ROMs are made by Sharp and are (currently) not known for failing. Just to be sure I put
sockets in place and replaced them with EPROMs but it didn't make any difference, those ROMs still fail. The game plays perfect with no
graphical issues so I can only assume that the data isn't getting back to the CPU and it thinks they are bad. The only extremely minor issue
I see comparing to MAME is in MAME the 'Scene 1' screen is black and on this board that screen is red. I may come back to this issue later.
It's probably just another bad Fujitsu logic chip somewhere. For now it doesn't matter so I'm going to move on.
The sound issue is next. Let's have a look at the schematic first. There's two pages, one for the Z80 and YM2151 and one for the uPD7759 sample player chip....
I first checked that the Z80 has a clock signal on pin 6 and reset signal on pin 26. They were both present and correct when I probed them
with my logic probe. I powered the board off then on while probing the Z80 address lines and the Z80 runs for about 1 second then quits,
meaning it was trying to run code but has crashed. I piggybacked the RAM at location F16 (which is a Fujitsu RAM) but believe it or not this
Fujitsu RAM is actually reliable! Piggybacking didn't help so I pulled the RAM and tested it in my chip tester but it passed. I added a
socket and replaced it with a known good chip but the Z80 was still not running code. I pulled and tested the sound program ROM at location
G13 but it matches MAME archives. The schematic shows the Z80 clock comes from the 3.58MHz oscillator at location G10. The clock goes into a
74LS04 at location D8 on pin 1 and comes out on pin 2. That 74LS04 is a Fujitsu logic chip but the Z80 has an active clock and appears to
be ok so the chip appears to be working. I even measured the clock with my frequency counter and it comes out on pin 2 exactly correct so
the 74LS04 appears to be working even though it's a Fujitsu chip....
Probing the clock signals with my logic probe again, on pin 1 the probe makes a normal beep sound and the orange LED is flashing to show
there's a clock signal present. Probing pin 2 of the 74LS04 (output) also gave a flashing clock signal on my logic probe. The schematic
shows the same 3.58MHz clock goes to the same 74LS04 into pin 9 and out on pin 8 then to the YM2151 pin 24 clock input pin. I probed pin 9
and got a normal clock signal. On pin 8 it was a static low. I measured the clock on pin 8 with my frequency counter and it came out exactly
the same as the frequency counter image shown above so the clock is good, right? Hmmm, well I'm not happy that the signal is only low on my
logic probe. Maybe it's time to break out the CRO! I probed pin 1 of the 74LS04 and got a waveform that looks a little bit wonky but I assume
must be ok since it's coming directly from the oscillator. On pin 2 it's similar, but again probably ok since the Z80 was
trying to run code. I then moved onto checking the other pins 8 & 9. Probing pin 9 shows the same clock waveform but on pin 8 (the output)
it shows a straight line low signal at about 1 volt. Hmmm, could this chip actually be bad?
I pulled the chip and tested it in my chip tester and it passed! So the chip is good enough to pass the 3.58MHz clock as a frequency but not
good enough to pass the correct waveform. Anyway, I replaced the chip with a good one....
I powered on expecting there to be an improvement and all I got was a flash on the screen and then BAM! Nothing. The whole board was dead.
Nothing on screen. WTF? I looked at my power supply and the power LED is not on. Errr. Looks like the PSU has just blown LOL! I have plenty
of spare PSUs here but in the spirit of learning I'll have a quick look and hopefully it's a quick fix!
I opened the PSU and found the fuse is blown and there's a short to ground on the 12V output. The other power rails were not shorted. This
type of arcade switching power supply uses an old-school TL494 chip as the switching controller and are pretty simple and relatively easy to
fix as long as you keep spare parts.... and I do. At least for the type I like to use, either Peter Chou or
the more modern and still manufactured WEI-YA WY-03CM, which is essentially a Peter Chou copy. Don't be fooled into thinking that the
expensive Suzohapp PSUs are any better. They are exactly the same WEI-YA PSUs just rebranded ;-)
Easiest way to diagnose this kind of fault is just start removing parts in the 12V section until the short goes away. I pulled a few
electrolytic caps and tested them but they tested ok. I also pulled the double diode 3-pin IC (looks a bit like a big transistor) but that
also tested ok with my MG328 component tester. I used my multimeter in beep mode to check parts for a short and when I checked the two big
beefy diodes at D21 and D22 (marked '30DF2') they were both shorted to ground on both sides. I pulled both and tested them and one tested ok
but the other was shorted. I replaced it with a similar diode (600V 3A Fast Rectifier) and tested the resistance across the diode again and
it was about 200 ohms. I replaced the fuse, put it all back together, powered on and the power supply came back to life. Ok so that didn't
take too long to fix it, about 1 hour :-)
Unfortunately I've run out of time today so I will continue the TMNT repair tomorrow.
14th February 2022
A couple of weeks ago a local friend picked up a neglected Galaxian bootleg (short style) board. He dropped it off here a few days ago and
today is fixin' day. It was showing random garbage on screen...
I first checked the ROMs and found that some identified as the 'redufob2' set in MAME but a few of them were unknown. One ROM had a missing
leg so I soldered on a new leg and then dumped all the ROMs and plugged them into MAME. The game worked perfectly so I knew the ROMs were
ok. This set has been added to MAME as 'redufob3'. A tip for patching chip legs..... after soldering, sand off most of the solder blob and the
patched leg will look nicer :-)
Moving on, I pulled off the ROM board and noticed the legs underneath were corroded so I sanded the legs with fine sandpaper and plugged it
back in. At power-on the game was still showing random garbage, but moving almost like the normal Galaxian boot-up. Probing the ROMs with my
logic probe showed the code was running and just before resetting it was showing some text but it was very difficult to read. It was showing
BAD RAM x where the x was a number but not readable. There is a Galaxian test ROM available so I programmed the code to an EPROM, ran it in
ROM location #1 and it came up with a message...
I was going to start worrying but the message assured me I shouldn't worry LOL! That's a relief! Problem is this error isn't 100% crystal clear.
Despite the fact that the test code is for a 2716 (2kB) EPROM and about half of the ROM is empty (i.e. plenty of room for say... ummm, a
proper bad RAM location maybe??), whoever wrote the test code wanted to assure me to not worry by wasting several bytes on a pointless
'worry' message but wasn't able to come up with a better way to provide any more useful info about the exact location of this 'stuffed' RAM.
Here's a pro tip.... remove the 'worry' message and re-use those bytes to give the RAM locations.
After some research I found out that ORAM is the object RAM located at 4F and 5F on the bottom board. These are 2x M5L2101 256x4-bit SRAMs
and were commonly used in late 70's arcade PCBs including Bally MPU pinball boards and also used in the RCA Studio II game console and the
clones Victory MPT-02 and Mustang 9016 Telespiele. I know this because I recently looked at the Victory MPT-02 and Mustang 9016 consoles I have here, dumped all
the carts I had access to and updated the Studio II hash file in MAME
with some proper documentation and added all homebrew games, as well as repairing both consoles to get them working. Those same RAMs are possibly used in several other things too.
I pulled both chips and tested them in my IC tester. One passed and the other failed. I have a few spare chips here so I put back the good
chip and replaced the bad one with a good chip. I put back the original ROM, powered on and expected the error to be gone but I got
It's the same error but the moving start-up test garbage is now the correct color. Hmmm.
I re-tested with the test ROM and it still
showed 'ORAM STUFFED'. I tested both RAMs again and they both passed. Just for curiosity I replaced the other RAM that previously passed
with a different RAM and got this...
Ok so the game is working now. I tested it and it appeared to be ok, including sound.
I played the game for a while and noticed that the explosion/death sound didn't play at all. There is a very nice 2-part troubleshooting manual
available that was put out by Midway back in the day. If you have a Galaxian PCB (including the bootlegs which are a 1:1 copy) and it has issues you should definitely check it out. The manual is available in many places on the net, for example here
There is a section on the sound and it gives some info about things to test specifically for a 'Bad Explosion' problem....
After going through the troubleshooting steps listed in the 'bad explosion' text, everything checked out ok. While probing pin 7 of IC9L
and diode D1 I could see the explosion sound signal showing up as activity on my logic probe, so the sound was definitely being made but
it wasn't coming out of the speaker. Obviously a part on the output side was faulty. I pulled up the schematic and traced the explosion
signal from the 74LS259 at IC9L to the amp chip and speaker output...
If you follow the red line you will see the 'hit' signal goes through a 1K resistor at R89, 4148 diode at D1, 4066 at 7R, 150K resistor at
R35, cap C23 and into pin 2 on the LM324 at 7T. The LM324 is the first suspect. The hit signal goes in on pin 2 and the fire signal goes in
on pin 5. The fire sound was working so the LM324 should be ok but it's possible just part of it has failed since a LM324 is a common failed
part. I piggybacked the LM324 with a good working part but the explosion sound was still not heard. Additionally I probed the input (pin 2)
and no signal was present so it's not even getting to the LM324. Working backwards, the troubleshooting info said to test the sound on R89
and D1 and it was present there. I also checked it on pin 4 of the 4066 (input) and it was also present, although strangely the repair info
didn't mention this in the 'bad explosion' section, nor to check the output heh! They did mention it on the 2nd page but not specifically
relating to the explosion sound. The output is pin 3 and on my probe it was silent! I piggybacked the 4066....
Yep that fixed it! I pulled and replaced the 4066 and that fully fixed the sound issues.
The first pic doesn't show it, but when it came in the board was pretty rough and dirty and only had a piece of cardboard between the PCBs.
No feet, no spacers, no screws. I found some and went to fit them but discovered an issue with the PCB...
With the front screws in place there's no holes for the spacers at the back of the board near the joining cables! WTF??
If I move the board to the back to use the rear holes there's no matching hole on the bottom board and the top board holes would line up
with traces on the bottom board so a hole can't be put there. I suppose it's time to drill some D.I.Y. holes at the back heh!
I checked a different near identical board here and it looks like someone did exactly the same thing with that board many years ago so it
looks like a common issue hehe! Ok so now it has 4 spacers, 4 screws and 4 feet fitted and is back to normal heh!
3rd February 2022
As always I've been busy with lots of repairs. Here's a few that were done recently.
This one is fairly easy. The screen flickers quickly. When looking through a camera half the screen is good and half the screen is bad. This is a known issue... at least to me ;-)
One of the 4464 video DRAMs is bad. Fairly easy to find the right one by simply piggybacking a chip over the top.
After a quick chip change it's working again.
Truxton / Tatsujin
Just shows an error on bootup. The board is not in great condition and there's no schematics available. Mission Impossible!
I have no idea what L-UP means, but the number shown is 01447fe. Now if you check the MAME source for Truxton you will see something interesting.....
You'll be surprised what you find in the source code of MAME. Always look for big red arrows in the source! ;-)
The source shows the memory map and that number is in the range of the bgpalette (background palette). The full range is 0x800h bytes, or
2kB. There's another one shown below it with range 146000 - 1467ff (another 2kB).
Now which chip is 2kB and is for the color RAM? There are several 2kB RAMs on the board so actually I have no idea. Piggybacking a 6116 RAM
on all of them had no effect, but shorting out the data lines on two of them affected the colors. I did not know which one was the bad
chip so I just pulled one of them, tested it in my chip tester and got lucky!
Now the game boots up. Clearly this was the original fault from back years ago before it developed this fault and was then abused and tossed
around in some losers shed.
It's not obvious from the pics here but there are lines through the sprites. There's always something else! :-/
On this board the sprite ROMs are labelled B65 01, 02, 03 & 04
First I pulled and read all those ROMs and they matched MAME archives so all ROMs are good. I probed the pins of all these ROMs with my
logic probe and noticed pin 10 was dead with no activity on all 4 ROMs! These ROMs are 1Mbit 28 pin mask ROMs and not directly replaceable
with common EPROMs without modifications to the PCB so hopefully it's just a bad connection. That pin is A0. I scratched the nearby traces
and tried to get a continuity reading but I couldn't get a beep for A0 or A1 from any visible traces. Time to pull some chips! As expected,
there's a broken trace right next to the hole for pin 10 so A0 wasn't being driven. I patched the trace and replaced the crappy socket and
that should be it, right?
Actually no! It didn't make any difference!!!
WOW! Another fault? (cue Mission Impossible music....)
Well the next step might be the bank of 2148 SRAMs. They are all running really hot and one or more might be bad. I
piggybacked them all but it didn't really make much of a difference. I probed the RAM inputs and a couple of them looked wierd. I traced those
inputs to a couple of 74LS373 logic chips and noticed some more water damage nearby so I pulled them.....
Yup! More broken traces caused by water! I patched the trace, replaced the logic chips and it was finally fixed!
Sadly this board will probably develop another fault eventually because of the poor condition.
To avoid that keep your boards clean and dry people!
This is a bootleg, but has a nearly identical layout to the original and without any (nasty) custom chips.
Boots up and shows an error 'WORK RAM : NO GOOD'
The work RAM on any arcade PCB is always the RAM connected to the main program ROMs. On this board it is 2x TMM2063 SRAMs. I changed one of
them and now it passes all the RAM tests buts gets stuck on another screen....
The other work RAM is the same type TMM2063 which is a known issue on many PCBs, so I changed that one too and now it boots!
The colors are not right. There's some sort of red in the background, but the main red is missing. On this board the colors go through 2x
6116 color RAMs then 3x 74LS367 logic chips then out through 5 resistors (a set of 5 for each color) that have been shoddily soldered
together. I piggybacked the top 6116 at IC165 but it didn't make any difference. I pulled and tested it but it was ok. I piggybacked a
74LS367 logic chip over the top and when held just right the colors came up good. The border was still red but that warranted pulling and
testing the chip but it tested ok.
Maybe there's a broken trace somewhere. I made a really quick and dirty schematic of how the chip is wired. 4 pins go to the RAM and 5 pins
go to the resistors. The resistors are (from right to left) 4.7k, 2.2k, 1k, 470, 220. That all checked out ok so no broken traces there.
Maybe there is a broken resistor. Since they are all soldered together it's difficult to see so I pulled and tested the resistors. When I
desoldered the 5 resistors from the PCB the first one separated by itself and fell off! If you look really closely at this pic you can just
see the dry joint on the first resistor!
I resoldered the resistors and that fixed the issue with the colors.
I played the game and some sounds were missing. I checked the sound section and a couple of caps were broken so I replaced them, reflowed and straightened all the others in that same area and that fixed the sound.
Now for something completely different!
A local friend gave me a Namco Guncon-45 Playstation light gun as payment for fixing some of his stuff....
It doesn't work but it can't be that difficult to repair, right? ;-)
When testing it with Point Blank the game shows the calibration screen but aiming and pulling the trigger does not advance to the next
screen where it shows the cross-hair and you can move it around on the screen. Pulling the trigger does nothing and it just keeps asking to
aim in the middle of the screen and pull the trigger. The shot sound is made so the trigger is working. Inside is a small board with a small
number of components. Looks like a relatively simple microcontroller and a light sensor with a lens to focus the light onto the sensor. The
easiest thing to start with is to check the cable. I beeped out the connections from the Playstation end of the cable to the gun PCB end of
the cable and found 2 wires (pin 3 and pin 8) not connected. I did not know if those wires were supposed to be unconnected or not. Looking
up some info on the net suggested the 2 pins were supposed to be unconnected but I did not have another Guncon-45 to compare against but it
seems plausible that they are correct because pin 3 is 7.2V for a feedback motor and pin 8 is listed as unknown so likely not connected
The next step is going to require swapping a few parts I think, but I have to consider the best way. The most obvious route seems to suggest
the sensor might be suspect. I looked inside my Namco Time Crisis arcade gun and noticed that the sensor looked exactly the same. This gun
is very simple and is only a sensor on a small PCB, a connector with 3 pins and no other parts. The sensor also has 3 pins so it's a 1:1
connection. The board for Namco arcade guns with the sensor and connector is available to buy new but the price is ridiculous... it's 2 bucks
worth of parts for $66! I didn't feel like bending over to get a rectal examination today so I took a chance that it might be identical. I
desoldered the sensor from the Guncon and swapped that into the Namco arcade gun, tested it with my Point Blank arcade PCB and it worked so
that proves the sensor is ok. The actual sensor seems to be completely unknown so just for kicks I researched it for a few days and
eventually figured out what it was and ordered some spares. When they arrived I swapped in a spare sensor into the arcade gun, tested with
Point Blank arcade again and it works so looks like I might have to make some re-productions of the little sensor board used in Point Blank,
Time Crisis 1 and Time Crisis II guns to thwart the rip-off merchants hehe!
On the Guncon control board there are many other small SMD parts (resistors/caps). I measured the resistance of every SMD resistor on the
board one by one and they all checked out ok. It's more difficult to measure SMD caps in-circuit so I removed every SMD cap one by one and
tested them in my MG328 component tester and they all tested good. On the back of the board is an 8MHz crystal. I tested that with my
frequency counter and found that it measured correctly so it must be ok.
On the board there's another small SOIC8 chip. This is a BA7071. It's a sync separator and if it's not working that would cause the gun to
not register hits. I did not have any chips in stock so I ordered 5 for 2 bucks from China and they arrived about 1 month later. I swapped
in the sync chip and expected it to be working but it still didn't work! The funny thing is when I used IPA to clean off the flux the
writing on the chip came off! Hmmm, maybe the chip is fake. I compared one of the other chips and they look legitimate enough with the same
package and round intent and I don't see the Chinese rebadging a chip worth 20c so it might be ok but I have no way to test it. Now I'm kind
of screwed because I have no more options to try.
So what do you do when you have no other options? Well you go out and buy a mint new-in-box Japanese Namco Guncon-45 for spare parts, that's what you do!
It wasn't that bad, only 60 aussie dollars and I've been wanting one for a while anyway. I'm sure it's less than they were when new. This
one is working fine and has none of the silly orange crap stickers like they do here in Australia. This is a proper gun that you can use to
hold up a bank, or at least that is what losers in the government believe because over here you can only get bright orange, red or blue
arcade/console guns. It seems that in Japan people are smart enough to know that a plastic gun with a 3 foot cable hanging out the back
doesn't make a good bank hold-up weapon, but here in Australia Aussies are not too smart and would probably try it so the guns are all
bright colors so we can't hold up banks! But the government losers forgot about paint. Never underestimate a can of black paint since it can
mask an orange plastic gun and make it look like a real one then bam(!) it becomes an instant bank hold-up gun! Nevermind that the barrel is
blocked off and has a plastic clear lens at the end of it. It's black so it must be real! This same problem also affects the new pc-based
made-for-MAME Sinden Light Gun coming from the UK. But even worse, customs people 'confiscate' them because they are a 'dangerous
weapon'. We all know they are bored and stuck in a rut with a low paid dead-end government job where people who flip burgers at McDonalds
make more money and they are always looking for ways to acquire free new shiny toys to use in their man-caves with MAME. You can't fool us damn
Uh hum, getting back on track, so inside the black gun it's identical of course. I first tried the easiest and less intrusive thing by
swapping the cable by desoldering it from the PCB at the connector and soldering it onto the non-working board. That didn't make any
difference. The next thing I wanted to do was prove the BA7071 sync chip was good so I removed it from the non-working board and put it on
the working board. The black gun worked fine so the replacement sync chips are ok.... good to know!
I also swapped out the 10uF 16V SMD electrolytic cap but that also didn't change anything.
So at this stage I've swapped the cable, light sensor, SMD electrolytic cap and the crystal is working. I've measured the SMD resistors/caps and
there's nothing remaining.... hmmm.... except the custom chip. Urgghh! Ok well I decided I must know either way so I desoldered and swapped
over the custom chip and that has to fix it!
I tested it and the gun still doesn't work! I took the original custom chip I removed from the non-working board and put that onto the working
board and the black Guncon still works so the custom chip is ok.
Hmmm, now it's time to get serious. If you thought I was serious before you ain't seen nothin' yet!
I found a schematic on the net but it's incomplete so I reversed the board and made a rough and dirty schematic.....
You're probably thinking 'wow that looks rough and dirty!' Well yes it is, I already said it's rough and dirty, pay attention people! ;-)
Regardless of how bad it looks it's 100% complete and if you view it full size it's plenty readable ^_^
When making the schematic I removed all the caps on the working board and checked them out of circuit. The caps connected to the crystal
measured a strange value, but swapping in some more standard 22pF caps caused the gun to not work at all. On the non-working board I used my
multi-meter and the schematic as a reference to beep out all the connections and they were all ok.
Maybe I should check to see if the thing is active. I had no easy way to hook up my logic probe so I soldered some wires onto ground and
3.3V and hooked up my logic probe.
According to the incomplete schematic I found on the net, pin 9 of the custom chip should have a 1kHz signal on it. I assume that's only
there as a test point just to check that the custom chip is working. I probed the test point and it was active. I used my frequency counter
to measure it and it showed 1kHz so the custom chip is working. Well I know that anyway because this custom chip is the one that came from
the working gun ;-)
So now what? Well there's no point probing the non-working board further because I have nothing to compare it to. So I hooked up some wires
to the working board and went over the entire board and checked all the connections at each part and stored that in my brain. With the
Guncon plugged in and Point Blank running on the Playstation I probed the sensor output and noted that the probe changed from static high to
active when the sensor was pointed at the TV and when I covered the sensor with my finger the signal went back to high again. This shows
that the sensor is working. Then I transferred my logic probe to the non-working board and probed all the same points. It
all appeared the same except the composite video signal on pin 9 of the cable connector. On the working board the signal was a normal
composite video signal. On a logic probe that means it's a low active signal but through the logic probe piezo speaker it sounds dirty and
growly like an angry dog. On the non-working board the video signal was just low, but not completely dead, with very minor activity.
It sounded more like a slightly annoyed guinea pig hehe! ;-)
Let's have a look at the BA7071 datasheet....
The datasheet shows the input is on pin 1 and output is on pin 8. There are some other outputs too but on this board they are not connected.
I probed the sync output from the BA7071 and it kind of looked about the same as the working board but I suppose it's very subtle after the
video is stripped out of the composite signal. The input pin 1 also probed as a low almost non-active signal. Something was pulling the signal
down. Well there's only a few parts between the connector pin 9 and the BA7071 input pin.....
I removed the 220 ohm resistor at R6 which is directly connected to the cable connector pin 9. This effectively isolates the PCB from the
video input so that the PCB has no effect on the signal. I probed the cable connector pin 9 and the composite video signal was present and
active. The angry dog was back! I checked the resistor I removed and it measured 220 ohms so it was ok. So the problem had to be with the 3
SMD caps. Those caps are in parallel and when you measure caps in parallel they just get added together. On the working board it measured
around 1uF across the caps. I measured the caps across the same point on the non-working board and got around 375nF. Hmmm, that ain't right!
Since the caps are in parallel it's impossible to measure them individually so I removed all 3 using hot air. Hmmm, but I did that before
and they tested ok??? I tested the caps individually using my component tester and one of them would measure good the first time, but when I
checked it immediately again it would not give a reading and the tester would just sit there trying to test it but never show the measured value. Ah!
That explains why I got a good reading the first time.... it gives a good reading when checking it fully discharged but not when checking it
again after it is charged. When I checked the caps originally I was tricked! Out of circuit the good caps measured about 360nF. This doesn't
seem to be a nominal value. The closest I found was 330nF. The next nearest is 470nF. I didn't have either in stock in 0804 SMD caps. Since
the caps are in parallel the actual cap value connected to the input is really just 1uF. I did have a 1uF SMD cap in stock so I just left
all the old caps off and fitted a single 1uF SMD cap. I replaced the 220 ohm SMD resistor, powered on the Playstation/gun and checked the
sync input on pin 9 of the cable connector with my logic probe and the video signal was active. Looks like it's fixed! I loaded Point Blank
on the Playstation and at the gun calibration screen I aimed and pulled the trigger....
YUP! The cross-hair appeared and moving the gun also moved the cross-hair. The game asks if the gun is aligned correctly, which of course it
is now that it's working :-D
So the fault was just a bad SMD cap that was pulling down the composite video input. Funny how it's always
the last part you check/change, but in this case it really was the very last part on the board. If it wasn't that cap there was no where to
go next hehe!
Finally, to finish it all off I removed all the silly orange stickers and cleaned all the scum off it so it looks new. Now I'm ready to rob
a bank with it because without the orange stickers it's totally believable that it's a real gun ;-)