Corrado Tomaselli

No background in electronics. Learned everything by reading pdf books and expecially Video game logic Vol 1 by Atari and in general early Atari and Williams arcade manuals

Metro Cross repair log ( same hardware of Baraduke)

General, PCB Repair Logs Comments Off

Mar 302020

The game at first didn’t boot due to the watchdog circuit being triggered.

There were 4 work srams by Toshiba and first one from left was faulty.

Unfortunately soon after , game started to reset again and the second sram from left failed.

The PCB had then all sprites in a single row and was missing the text on the upper and bottom area and soon after it losts also the BLUE component

Decided to start from the easy part and restored the missing colour.

Green and blue components are generated by the PROM @ 1N.

Signals were good so the fault was in the 74LS173@2P which had all output stuck at 0V

After changing the TTL I restored the blue component.

The missing text was due to the 74LS195@6L , while checking it I saw that the text reappeared but glitched

After changing it I finally had again the text

To restore the sprites I decided to concentrate on the \HSET signal on the sprite address generator circuit.

This signal comes from pin 22 of CUS35 and it was always stuck LOW. I took another CUS35 from a Baraduke board and the problem remained.

So I decided to look at the other side and checked two 74LS173@9N and 9P

I shorted for a brief moment the \Hset signal to 5V and the sprites were correctly drawn again and the signal was oscillating.

But I noticed that some sprites has some glitching on colours.

I decided to replace both of them

Board was 100% fixed

Of particular note is that all the faulty TTLs were by Texas Instruments ( not Fujitsu!) and of uncommon type.

It seems Namco had a stock of these ICs to be used on an hardware design 😉

Please note also that CUS35 is 100% compatible with CUS48 from later Namco system 1 games.

Pacland repair log #5

General, PCB Repair Logs Comments Off

Mar 292020

Second Pacland pcb I got for repair is a Namco one.

It had some sprites wrongly selected by the game code

After checking on the schematics the sprite addressing I found this:

pin 16 of 74ls377@7K was stuck low thus selecting the wrong sprites on the sprites eproms

After changing it board was fixed:

Pacland repair log #4

PCB Repair Logs Comments Off

Mar 292020

Got two Pacland pcbs to be repaired from a friend.

Fist one is a Sidam Pacland which showed the following problem:

All the screen had shadowed colours going up and down vertically.

By expecience whith similar problems on different hardware I understood it was a Hblank problem.

The game didn’t shut off the screen at the borders so the monitor didn’t have anymore the black reference.

Looking at the schematics I found immediately a clear reference to the blanking circuit:

Compblank was oscillating, while COMPBLANK A and \COMPBLANK A were stuck.

Chaning the 74LS74@6M fixed completely the issue

Desert Breakers repair log

PCB Repair Logs 3 Responses »

Dec 302019

Bought a cheap Desert Breaker for my collection which the seller declared as having no sound.

This game is running on system18 hardware. Since the sound was totally missing I first tested the z80 which was good and then I desoldered the SRAM which was

a Toshiba @IC79 , normally very unreliable in comparison to other makers and infact it was faulty.

It fixed the sound but playing I noticed that some sprites had missing lines

This problem could be either the custom chip 315-5361 ( sprite generator ) or the srams connected to it ( IC21 and 22)

Since all the address line were good, I proceeded to desolder and test the srams which were infact bad bad.

Game was fixed totally

I have a ninja spirit on my collection since more than 10 years. I play it regularly but the other day it once powered up the foreground layer had some vertical black bars crossing the screen for the complete height on the right side.

After a while also the left part started to blick glitching ( cannot be seen on the screenshot below unfortunately)

The board is an irem M72 and the background and foreground layers are handled on the bottom board. The circuit for both playfields is completely the same.

Schematics are available for Rtype which is the same hardware minus the C board.

I checked immediately the circuit which draws the foreground and decided to check a couple of TTL

With some luck I immediately found one 74ls283@10A (IC 78) which was glitching badly the left part of the screen when testing with the probe on pin 10.

74LS86@7B ( IC50)was also glitching the screen when testing with the probe on pin 6