Data I/O 29A & Unipak2 repair log

 Equipment Repair Logs, Repair Logs  Comments Off on Data I/O 29A & Unipak2 repair log
Jun 072017
 

I bought this setup from a good friend quite a few months ago now. I knew it needed some attention when I bought it.
On power up I got this most of the time

No response from any inputs from the keypad.
The keyboard generates an interrupt for the 6802 CPU. Using the scope I could see the /IRQ signal was being asserted.
I checked all of the ROM’s and found no issue and also checked to surrounding logic and found no issue.
Looking around the main PCB I found a couple of problem areas.

As you can see, both of these chips had some corrosion. I replaced them but they made no difference to the problem I had so after a while I came to the conclusion the CPU must be bad.
Searching eBay turned up nothing UK based so I fired off an email to my friend, Purity to see if he had a spare I could buy. He had one and said I could have it.

And now I get this

Problem solved.
Next issue was with the Unipak 2 itself.
I could successfully select and read chips but the data being read back was a little wrong.
Reading a few carefully selected addresses of an EPROM I found that bits 2, 3, 4 & 5 were stuck high.
Looking at the schematics I quickly came to a potential problem area.

You can see from the schematic above that the LM339 comparator is responsible for those exact bits.
I removed the chip and tested it out of circuit. The chip failed and I ordered some new ones.

With a new one fitted everything was back to working status.

I’m really happy to finally have this in my collection and working.
Massive thank you to Purity for his generosity. He has been very kind to me recently and also a great help. I hope one day to be able to return the favor.

 Posted by at 5:17 pm
May 252017
 

I got for my collection an untested boardset of Defender which was really in great conditions with no battery acid leak.

The boardset is the newer revision of Defender with the red label roms.

The game is very difficult to find it in working conditions nowadays because it has several weak points, expecially the 24 drams 4116 which are very unreliable to due the fact the run very hot and they require +5V, -5V and +12V to be applied at the same time, otherwise they will be damaged.

The old Williams PSU become defective and often they ruin the drams.

After converting it to Jamma and triple checked all the power supply lines I booted it up but the game appeared to be dead.

Fortunately Defender has a lot of bibliography and a very good manual which is also a troubleshooting guide.

I check the clock and it was working correctly, but after checking the reset line I saw it was pulled low all the time.

To make it short, Defender has two +12V power supplies, one regulated and one not.

You have to supply +12V also to the not regulated one because it is needed for the power on reset.

After adding that +12V t, the game booted but as soon as the message ALL UNIT OK was displayed it reset in a never ending loop.

I found out that the problem was caused by the ribbon cable , after reseating it a couple of times, the game booted correctly.

I started the game but the ship kept always going down.

With the test menu , it reported that the down direction was always pushed.

I checked the interface board which has the circuit for the inputs. the hex inverters 4049 were all toggling correctly, the pull up resistors were good therefore there was only one chip to check: the Peripheral Interface adapter 6821P.

I desoldered it and installed another one I had on stock taken from another arcade games.

Since I had no way to test it, I decided to put a 40 pin socket just to be sure I could easily swap it with another one in case it was defective.

Luckily the inputs were now correct, thefore I could declare the board fixed.

In the end I was very lucky because the game had only the input problem and no other issues.

 

Rastan repair log #5

 PCB Repair Logs, Repair Logs  Comments Off on Rastan repair log #5
May 252017
 

The game had some missing background tiles

 

 

At first I thought it was a maskrom problem but once I checked all of them only to find they were good, I started to probe the ram responsible for the background.

A sram @IC31 had some weak data signals so I decided to change it and the guess was right because the game was fixed.

Michael Jackson’s MoonWalker repair log #1

 PCB Repair Logs  Comments Off on Michael Jackson’s MoonWalker repair log #1
May 212017
 

Another board from the recent operator raid, an original Michael Jackson’s MoonWalker (on Sega System 18 hardware)

Despite its age and the use of the FD1094 CPU module with battery backed-up RAM the board was still working except for the sound samples (drums, speeches, etc..), they were missing or replaced by random ones:

The hardware uses a rebranded Ricoh RF5C68 as PCM sound chip :

Not able to find any datasheet I went to “listen” its pins with an audio probe.When I hit the analog outputs (the IC has an on-board DAC) I realized that sound came already wrong out of it.So the chip was the only responsible and it needed to be replaced:

Done and…success!Board completely fixed.

 Posted by at 9:50 pm

Asterix repair log #1

 PCB Repair Logs  Comments Off on Asterix repair log #1
May 212017
 

Another Konami PCB on the bench!

Picked-up this Asterix PCB in a recent operatot raid:

Board was physically damaged, one part of PCB was litterally missing and the nearby 16Mbit MASK ROM was cracked in half:

The affected part was not a vital section of circuit (but only a spare room for not used additional MASK ROMs) so board still booted but sprites were missing.If I pressed the ‘053245’ ASIC they came back but garbled and blocky:

For first I reflowed some bent pins of the ‘053245’ sprites generator:

Then I replaced the broken 16Mbit MAS ROM @3K with a compatible 27C160 :

This improved things but not still perfect :

The MASK ROMs check complained about the other device containing sprites data (the one @7K)

Like said in my previous Parodius DA! repar log, this doesn’t necessarily imply that IC is faulty but also that it cannot be reached  by the device which wants to read/write it.Address bus is shared among the two MASK ROMs @3K and 7K, doing a check with my muktimeter all was fine except for pin 42 of both, I got no continuity between them :

Pin 42 is the higher address line:

I simply ran a jumper wire, this restored sprites and fixed completely the board:

 Posted by at 7:05 pm