May 262016
 

I got from New Zealand this genuine Splatterhouse PCB for a repair:

Splatterhouse_PCB

Upon boot the board was stuck on a “ROM TEST START !! PLEASE WAIT…” message displayed upside down :

issue

From my past experience I know for sure this issue is caused by a bad ’64A1′ custom replaceable with a programmed Hitachi HD63701 MCU (plus a patched ‘VOICE0′ ROM in order to handle two custom opcodes of the ’64A1’)  following this procedure:

Namco System 1 custom ’64A1′ replacement

But in this case, as you can see from the above picture of the board,  the owner already replaced the ’64A1′ (and at same time  patched the ‘VOICE0′ ROMs using an hacked 1Mbit JEDEC EPROM in place of a non-JEDEC one ) and this didn’t fix the issue.For first I reverted the modification the and reinstalled the original custom ’64A1’.With this configuration the board successfully booted into game although some sound samples were bad.This lead me to think that there could be some problem is the data bus of the VOICE ROMs which prevented the HD63701 MCU to correctly read the patched data causing the missing boot. :

VOICE_ROMS

So, assisted by schematics, I went to check the involved circuit and found that pin 20 (data line D6) of the VOICE ROMs (Splatterhouse use only four of them to store samples) was not daisy-chained as it should have been:

VOICE_ROM_DATA_BUS

In the above snippet of schematics you can see (red mark) where extactly trace was interrupted.I simply used a bit of AWG30 wire to restore comnection:

patched_PIN20_VOICE_ROMS

This fixed completely the game using both the original ’64A1′ custom and the HD63701 MCU.End of job.

 Posted by at 8:19 pm
May 222016
 

The 14″ TV is up now.
This one was a lot more involved.
Before starting on this one I had tested the previous PCB with this TV so I knew for sure the TV part was operating fully.
sf1-repair

When powering this up I got no audio or video, just a black screen. Using the external A/V output also gave me nothing.
I couldn’t find anything obvious visually on the PCB itself.
Ive read a lot in the past about SNES repairs and the CPU’s seem to be a weak point. I started prodding around the CPU with the scope and even though all the voltages and clocks looked good I could see any activity.
I had a known working spare SNES which I opted to sacrifice for parts.
sf1-pcbmark

I replaced the CPU and once again checked for signals. This time I had life but it gave up after a few seconds and still didn’t give me any output. This cycle was repeatable on resetting the machine.

I next opted to replace the ‘S-WRAM’ (work RAM) positioned next to the CPU.
Replacing this gave me audio but no video so at least I knew the game was running which was great to hear.
At this point I tried the external A/V connector again and got a good picture.

Probing the ‘S-Enc’ chip yielded no outputs at all despite all inputs being as expected. I replaced this and everything came up good. Time to reassemble and reclaim some bench space.
Thats both of these rare units fixed up.

sf1-pair

 Posted by at 10:21 am
May 212016
 

A couple of friends were looking to get their SF-1 SNES TV’s repaired. Not one for letting such gems go to ruin I offered to try and help out.
There were two units in need of repair, a 14″ and a 21″.
sf1-top

This log will focus on the 21″ version first.

On power up with a game fitted I got audio and a very faint greyed out picture.
I had been given an RGB scart cable with these so as they have the standard A/V output port on them I thought I’d give that a go.
I got this
sf1-sync

As you can see the sync signal is off but I could see a nice colour picture. This gave me initial hope that the PPU’s were not to blame for the grey faint picture.
Taking this unit apart was a bit of a pain with the SNES part being sandwiched in at the top but I got it out and looked for anything obvious.
sf1-pcb

(Note that this PCB image is actually from the 14″ version. The 21″ version has a very similar PCB with only the connector location being located differently. I forgot to take a picture of that one.)

There was nothing obvious so start looking at the missing sync signal first.
The answer was fairly straight forward. The RGB cable I have here uses the composite signal for its sync. The SF-1 does not seem to output a composite signal at all instead it uses the combined HV sync signal on pin 3. Hooking this up instead gave me a nice picture on my test monitor which confirmed the SNES was working great.
So whats happened to my picture on the actual TV unit?
It turns out the SNES outputs separate Luma and Chroma signals to the TV for its picture and not RGB like we initially thought.
sf1-connectors

The connector marked ‘VD’ is the video signals. The black wires are all grounds and the white wires are signal. One of the wires however is the audio output. So there is Luma, Chroma and mono audio on this connector.

Now I know the signal isn’t RGB I can pretty much assume that the ‘S-ENC’ (BA6952F) is used to generate the signals i’m missing.
Using the scope I couldn’t find any valid signals coming from the chip. In my haste I was about to write the chip off but as the output signals were really weird I traced all of the pins. I found the GND on pin 2 wasn’t connected at all and it should have been. I tried reflowing the pin but still no connected so I added a jumper wire to the GND point next to it.
20160518_205235

I was a little nervous about patching it as if the original track (that ran under the chip) had burnt out then what had happened to do that? It could have been a manufacturing defect, Ive seen a couple of those in my time but ground connections are generally quite big compared to signal traces. I didn’t want to remove the whole chip just to check for a burnt trace so I just check resistance between GND and VCC. It looked fine so I powered up to test.
21picture

An absolutely perfect picture! Seriously this picture is really good quality.
I tested all the controls and they seem to work fine too so time to box this up.

 Posted by at 8:18 pm
May 192016
 

Last year after a lot of research I succeded to buy at a good price an original board of Psychic 5 , one of my favourite game of all time, which was really in mint conditions.

 

psychic5

 

Some days ago I picked it up for a play and after some minutes the game developed this problem during attract mode:

psy5

psy3

psy2

 

After some more time the game was total yellowish:

psy4

 

Game hasn’t any schematics available and there are not any games known to me which have similar hardware and schematics available.

I could only go blind and try to find the reason of the fault.

So I started to short some signals of srams looking for palette changings and I found a couple of them at pos.6N and 6M, 16kbits.

The one at pos.6N had the first 4 data pins low and I was pretty sure either it was faulty or the 74ls245 connected to the data bits.

After desoldering, the sram 2018 was tested good in the programmer. That meant that the programmers didn’t use all data pins of the palette rams. The 74ls245 was good because it could drive correctly the signals without the ram installed.

I tested some TTLs nearby looking for strange signals but found nothing.

Decided to go brute force using my logic comparator and testing everything on the video board but starting with FUJITSU parts which are known to be very unreliable.

The logic comparator found a 74ls08 with all the outputs faulty

psy6

 

I double checked the outputs with a logic probe and they were all in the grey area (no good logic signal).

After changing it I fix the problem 100%

 

psy8

psy1

So FUJITSU brand proves once again to be really unreliable!

May 132016
 

More than a repair a quick fix.

I got this Dangun Feveron PCB :

Dangun_Feveron_PCB

The owner said that most of sprites were scrambled and I could confirm the issue upon powered up the board:

Sprites data are stored into two 42 pin 32Mbit MASK ROMs @U25-U26:

sprites_ROMs

When I went to probe them I noticed a broken jumper @JP3:

broken_jumper@J3

Checking with a multimeter the connections of this jumper relevealed that point ‘2’ was connected to pin 32 of the two MASKs ROMs, therefore the higher address line A20.So, signal coming from point ‘3’ was not reaching this pin due this broken jumper and this caused the sprites issue.Once restored it:

RSCN2919

all came back to normality.End of job.

 Posted by at 10:07 pm