Welcome to Pantman. Another good source of repair logs coming now.
Happy new year to everyone too
Jan 012016
Bosconian repair log #1
PCB Repair Logs, Repair Logs
Comments Off on Bosconian repair log #1
Dec 282015
I got this original namco untested pcb as a part of a deal.
As always happens, untested =not working and infact upon booting up it was totally dead with only a fixed static screen.
I was not too worried because I had a Dig Dug by Sidam which I use for spare parts and there are also schematics available (by Midway).
So I began my troubleshooting.
I checked the clock on the 3x z80s and it was missing.
Traced back to a dead output of a 74128@6B. The input coming from custom 07xx was OK.
I started to search for a replacement and I took my Dig Dug pcb but in place of the 74128 there was a socketed 7402.
Bad luck, someone put wrong TTL as a place holder….
I then discovered that this 74128 is not common at all and it is used only on early namco pcbs.
I decided to contact my friend Charles Mcdonald to have a suggestion how to make the pcb boot just at least to see if it hadn’t other faults.
He told me that this 74128 is a really weird choice because it is used to drive signals over long distances and a 7402 is the equivalent to drive lower mA, but I had to disconnect the R5 100ohm resistance.
In the end the guys at SIDAM made this “modification” on purpose to the original Namco design!
So I fixed the clock problem installing a 7402 and lifting provvisorily the resistance.
After booting up, unfortunately the game had another issue:
After some studying of the pcb schematics and some short circuiting I discovered that beneath these stripes there was the black background with the
stars correctly generated by the custom.
Worth of note is the score part of the display that was good.
On the video pcb there were 4x 4kx1bit rams 2147 which I didn’t have as spares (Dig Dug uses another video board) , two of them were running very hot .
Tested with the logic probe they were pulsing correctly.
At this time it was clear that the problem came from around there because shorting some pins changed the coloured stripes.
Disabling the CS line of the rams, restored good backdrop, stars and enemies but your ship and missiles disappeared.
So it was clear that these stripes where the “scattered” colours which should have been combined to make the ship correctly coloured.
I decided to test with the logic comparator the 74174@7D which is mixing the bits from the rams : it reported some bad pins.
When I changed it I got no better results, but I got another positive feedback that the problems came from the circuit near the rams.
If I left out completely the chip from the socket I got good backdround and no ship.
The enemies and bases are part of the background circuit.
All the TTL which were used to address the rams were good so it was clear that some or all the 4x 2147 rams were bad.
At this time I decided to give up and to order some new rams in the hope that the problem was really there.
Just before placing the order I decided to take another look at the 2148 ram @4J which on my pcb was not placed and I thought of a schematic mistake.
Now everything was clear : Namco prepared already the pcb to accept one 2148 ram which is 1k x 4bit instead of 4x 2147 rams, 4 k x 1bit !
The highest addr lines are not used so it can really be used as a replacement!
I had a lot of 2148 rams so I immediately desoldered all 4x 2147 rams and placed @4J the 2148 ram
Finger crossed and when the game booted up I was finally welcomed with correct colours!
Haunted Castle repair log #2
PCB Repair Logs, Repair Logs
Comments Off on Haunted Castle repair log #2
Dec 282015
Got this pcb from a friend of mine for a repair
The pcb had already all the sram chips repaired and some flying wires underneath because of broken traces.
Upon boot up, it constantly reset with this message:
First thing was to test the socketed sram chip 6264 near the 2 big customs but as expected they were good.
Tried to flex the pcb and it booted with wrong palette sometimes
Surprisingly once it booted it could be played with wrong palette all the time until the next boot.
So the code did only a check at the beginning.
After pressing and flexing everywere I found out that the game booted only when I pressed the Hybrid module 007327
I discovered looking underneath that the module has some small srams and looking at the schematics this is confirmed.
I turned out that one pin had a subtle loose contact. I reflown brutally everything to make it more resistant against shocks.
Booted the game and I was welcomed to a perfectly working game
Dec 272015
I had on the bench this Aliens PCB:
Board had sever sprites issue:
I performed a MASK ROM check which reported two bad 4Mbit devices @K2 and @K8:
I was able to exactly reproduce the issue by using two dummy ROM files in MAME:
So, without further delay, I went to remove these devices and install two 40 pin sockets for the 27C400 EPROM replacements:
With these replacements fitted sprites were perfect but I noticed that sound samples (like voices of main character or enemies) were missing:
Sound samples are stored in a 2Mbit MASK ROM @D5 (which is not checked by the self-test) and its data are processed by a custom marked ‘007232’ which is a PCM controller:
Probing the 2Mbit MASK ROM revealed no activity on data and address bus, all pins were stuck high so I removed it:
and replaced it with a 27C400 (with doubled content since no 2Mbit MASK ROM replacement exists).This restored all sound samples.End of job.
Dec 262015
Yes, yet another Rainbow Islands on the bench!
Once powered up the board, I was greeted by this static screen:
The watchdog was active sign that there were troubles in main code execution.For first I dumped the program ROMs and they were good (although they were from the Extra version so board was actually an hybird since C-CHIP was the one from the normal version).Then I passed to analyze the WORK RAMs (two Toshiba TMM2063) and I found weak signals on data lines of both:
This lead me to remove them, they both failed when tested in my programmer:
With good WORK RAMs the board successfully booted but sound was missing at all:
Fitted a missing 1000uF 16V capacitor @C84 in the sound section was not enough to restore sound:
I noticed that the RAM of the Z80 audio CPU was another TMM2063 which seems to be very unreliable part (like Fujitsu TTLs, I’d say..) so I went to piggyback the one @IC44 and sound was restored.The chip failed the out-of-circuit testing:
Yes, yet another Rainbow Islands PCB saved from scrap pile!