Pang repair log #2

 PCB Repair Logs, Repair Logs  Comments Off on Pang repair log #2
Jun 162015
 

Got a friends Pang PCB here for repair.
He had carried out the ROM swap (made by ArcadeHacker) to desuicide it but he had no output although we could hear it playing blind.
The board is very clean and a visual check revealed nothing.
On powering the board up I got this screen
IMAG1355

I could also hear the board did play blind so that’s a good sign.
I like to make little schematics for boards when I’m working on them and they don’t have any available and I quickly came up with this.
pang

I started probing back from the RED pin on the JAMMA edge connector and soon came to a RAM chip at location 8C. Probing this chip and its counterpart gave me some odd looking signals which I got suspicious about.
These chips are CXK5814 SRAM chips and they seem the be the most unreliable RAM by comparison.
One of the RAM’s had all its data lines stuck LOW while the other chips data lines were all dead despite all the enable lines working as they should and the address lines active.
At this point I was certain they were dead but one last test was to ‘piggyback’ a known good RAM chip on top of the suspected bad one. I chose the one with the dead data lines to avoid potential contention and I got a partial image on screen.

I desoldered both the RAM chips and replaced them. I didnt have any spares in my RAM bin but found a couple of skinny 6116 RAM’s on a scrap bootleg board.
IMAG1353
IMAG1359

Fitting these I now got this wonderful sight.
IMAG1356

IMAG1358

Job done.

Apr 142015
 

Had this board for a while now but hadn’t looked at it.
IMAG1239

On booting the board up I got completely messed up graphics.
IMAG1238

On my pre power up visual inspection I somehow missed the damage and solder blob on the 052109 tilemap generator.
IMAG1240

I removed the solder using solder braid and straightened the legs up best I could with some fine tweezers. It took a while as I didn’t want to snap the legs off but I ended up with something I was happy with.
IMAG1255

Fixing that gave me the graphics back but there were jailbars present.
IMAG1242

Jailbars are usually a sign of a failed ROM and as the two MASKROM’s have previously been replaced for a pair of 27C400 EPROM’s I thought it was best I check these out first.
Both turned out to be fine so the next step was to check the address and data line to see if they were active.
Again I could find no problems here.

I then found the test menu which runs a self test on these ROM’s. The ROM at location 16I gave a different checksum each time I ran the test. A changing checksum can be a sign of a floating data pin. I already knew the data pins were active and that the ROM’s were good so I set to work with the multimeter checking continuity between the EPROM and the 051962 tilemap generator which these data line go to.
Eventually I found data pin 8 did not make it to the 051962.
IMAG1243

I was able to patch this underneath the EPROM so it would be hidden (and protected).
IMAG1244

On powering up all the jailbars were gone and the board is fixed.
IMAG1253

Stun Runner repair log

 PCB Repair Logs, Repair Logs  Comments Off on Stun Runner repair log
Mar 292015
 

Had Muddymusic’s Stun Runner PCB for a long long time awaiting repair.
I put off looking at it because of how test bench unfriendly it would be to setup.
I did have most of the original loom to use but the audio section also used 13v AC and a test bench typically doesn’t have that.

I ordered a small 240v – 12v transformer and eventually set to work in hooking this thing up.
After half a day of messing around I had what I thought was a Stun Runner test rig.
While I had all the connections going to the right places and things like that I soon realised that the speakers I were using in now way suitable to check the sound and also my test bench monitors seem to be getting really picky about what they display properly.
In the end I settled for a black and white picture but I wasn’t too worried as the fault I was looking for was audio related.

The fault was that in game the music didn’t play and the engine tone played at a constant tone.
With my almost useless setup I could hear exactly this. I did a quick heat check with my finger on the audio PCB to check if any of the chips were getting hot and to my surprise all the sounds and music came back when I prodded the M6295.
IMG-20150310-WA0005

I powered down and reflowed the chip and all was working again.
I soak tested it as best I could and called it a day.

Muddymusic has now got it back and has confirmed the sounds and music are now good.

SEGA Mega-tech repair log

 PCB Repair Logs, Repair Logs  Comments Off on SEGA Mega-tech repair log
Feb 072015
 

Some weeks ago I was sent a Mega-tech board to look at with an apparently common fault. The PCB would not see any cartridges that may have been present.
As it is considered a common fault I thought it best I draw some schematics up in order to allow others to hopefully fix their own fault. What I found with this system was far from easy.
NOTE: I use a variety of different displays throughout this repair and my test bench TV displayed the colours a bit wrong but its not a PCB fault.

The visual inspection turned up something straight away on the underside around one of the factory fitted wires.
IMAG1139
I cleaned this up and tested the board. It fired up OK but I could hear a strange ‘fizzing’ sound and occasionally a ‘pop’. As luck would have it I was in a darkened room at the time and I could clearly see that resistor array RA18 next to IC37 was glowing. This was located right underneath where the burnt out wire was.
I replaced the resistor array and did some continuity checks and everything was good.
I think at some point the wire had been pierced by an IC leg and shorted out. Maybe this is something for owners to check out?

This is what I got booting up
IMAG1132

The menu has its own Z80 processor and BIOS so I thought this would be a good place to start.
The first step was to take the code apart and see exactly what it does to read the cartridge ports.
Ultimately the Z80 sees the cartridges between address &8001 – $9fff, but before we can do that we have to jump through a whole set of hoops to setup the system. It is here I found my first problem.
I used the Fluke 9010 heavily throughout this repair so I had full control of this setup.

On this board there are a couple of CXD1095Q I/O extender chips. These chips require setting up before they can be used and the BIOS does this on startup.
They have 5 ports (A to E) and the pins on each port can be set as either an input or an output. To set these up the BIOS writes the necessary values to the registers of the CXD1095 at address $6406 and $6407.

My focus originally started on the one at IC7.
IMAG1154

So ports A and B are not used on this chip so they are set as inputs.
Ports C, D and E are set as outputs.
Port C lies at address $6402
Port D lies at address $6403
Port E lies at address $6404

Reading at address $6c00 clears the /RESET line to IC7. This needs to be done before the chip operates.

The port I was most interested in at this stage was port E as this is the one that selects cartridge slot to be used.
To setup port E I simply had to write the value 0x0 to address $6407 and then whatever I write to address $6404 should appear on pins 49, 50, 52 & 53.

This was not what I had though, instead all my pics were dead.
After convincing myself this chip really was bad I hit the internet and ordered a couple of replacements from China.

A week or so later and I had these replacements.
I removed IC7 and fitted a new one.
IMAG1157

Now when I ran the same tests I got correct activity on the output pins but the board still did not see any cartridges.
Moving on from here brought me to the second CXD1095Q chip at IC24.
The registers lie at address $6806 and $6807 on this chip.
This chip is responsible for reading various signals back including the “Cartridge Present” signal.
Address $6802 is the cartridge present signals and following the same testing as before I should have been able to write 0x3f to $6806 and then be able to read back values at address $6802. Again this was not the case so I removed and replaced this chip which gave me back all my signals. Like before this did not cure the problem.

The advantage I had now was I could setup the board so I could read the cartridge starting at address $8001. When I tried to read I got slightly different results each time, kind of like if one or two of the pins were floating. None of the pins were floating however.

As the Z80 is an 8 bit CPU and we are reading from a 16 bit bus there needed to be some other logic in the way. This takes the form of a custom chip marked 315-5309 at IC66.
Using MAME I knew what values I should have been reading back from each cartridge and I could confirm these readings using a logic probe on IC53. I could infact confirm the signals from the cartridge right back at the 315-5309 chip but the signals coming out of the chip back to the Z80 were different on each read.
I already had access to a spare 315-5309 so I took the plunge and replaced it. To my surprise it worked!
IMAG1162

On paper (or screen) this appears to be a fairly straight forward fix but I assure you I was pulling my hair out for most of it.
A huge thanks to Charles MacDonald for all his assistance and providing me with a proper datasheet for the CXD-1095Q chip.

Partial schematics can be found here

Dec 312014
 

today I got a couple of Oric computers.
Ive been after one of these for some time now but prices have shot up of the last 12 months.
I couldn’t resist buying these two, both of them which required repair, as the price was right.
IMAG1141

First is red/black one.
I first started by removing the ULA and powering up to check voltages. I do this with Spectrum’s too as these early voltage regulators have a habit of going wrong with disastrous consequences.
With everything looking OK I refitted the ULA and power up. I was greeted with this screen.
IMAG1145

Ive read enough about the Oric over the years to know that the ULA is very hardy and the RAM is very poor. Ive also read that a fried ULA will usually result in nothing on screen at all.
I opted to desolder the RAM first.
There are 8 x 4164 RAM chips and on testing two of them failed.
I socketed and replaced the faulty RAM and I now have this
IMAG1147

The random writing is my doing as the keyboard is flat on the bench when testing.
Happy with this. I think the second unit has the same fault too.