Nov 272016
 

Got this original Juno First (by Konami) for a repair :

100_9351

Board played fine but some sounds were missing, the most noticeable was the laser shot:

Here is a MAME record for a comparison:

All the sounds are generated by the AY-3-8910 chip.Probing it revealed that three I/O (pin 19-20-21) were stuck high, these should exchange data with same number of I/0 lines of the Intel 8039 MCU like shown in schematics:

80393r

The 8039  was dead,  clock was missing on pin 2 and 3.I replaced the 8MHz quartz and the two 10pF capacitors with no change.This MCU has no internal ROM so it needs an external one :

100_9353

Using a dummy ROM file in MAME reproduced exactly the issue, some sounds were missing like in my board.This lead me to think the MCU was bad so I removed it:

100_9355

The 8039 is not widely used on arcade system but I was luck and found one on a Gyruss bootleg.Installed a socket and chip:

100_9479

and all mssing sounds were back.End of job.

 Posted by at 10:47 pm
Nov 132016
 

Recently a user on the UKVAC forums released his home made tester known as the AR81 upon the world.
http://www.arcadetester.co.uk
Original forum thread can be found HERE

It has many uses and more are being added regularly. The most interesting to me was the ability to check TTL in circuit.
20161016_163945

It accomplishes this by storing states of known good chips and then taking a snapshot of all the pins at a given time then comparing the snapshot against its own database of stored states.
I’ve had pretty good results using this feature so far and found it useful enough to devote some time towards expanding its databases.

I currently have some concerns about how users of this will go about sharing their state map files. There is a github that has these files on which I believe is considered ‘official’ but what if I have a drastically different set of states stored in my file when I come to upload it, what happens to the states that might have been stored in the github version if I don’t have them in mine? Now its worth mentioning I dont really understand github and although I am aware of diff files I don’t know how they work or what their limitations are. It may well be the case that it can handle this scenario without problems. If it does then great, that’s one of my concerns dealt with.
My other concern is who’s checking these files? What if someone has uploaded a new set of states that is just wrong or flawed in some way? It could go unnoticed for quite some time.
With that in mind I set to work creating some tools to let me deal with both of these problems.
I know have 3 different program made.
The second two I made are closely related so ill deal with those first.
One of them can be used to merge two files together but will exclude any entries that are duplicates. It can also be used for checking an existing file does not contain duplicates or any other strangeness like incorrect formatting of the unused pins or the GND pin not being defined as 0 etc. Its final use is to display individual state maps on screen in a more user friendly format so they can be manually confirmed for correctness (or not). If not then they can be removed easily.
adtcheck

So far I have successfully used it to remove a few errors I have found among various files and I am currently in the process of putting a set of files together that I believe are functionally correct. If they aren’t in some way then at least the blame can be accounted to me and not someone else.

The third program I made is in early development but has been a massive time saver.
Take for example a 74LS245 chip. The total number of valid state combinations is 512. Now that’s excluding any states that occur while the /OE is HIGH. I personally don’t feel those should be included as the chip should be in high impedance mode. Others may completely disagree with me but that’s fine, I can see both sides of the argument. There is a new version of the software on its way that allows the user to specify and output enable pin and state so any test results will be ignored if not in the correct state.
Anyway, finding and saving all these states from a working chip in circuit is going to be a massive task. Given the relatively simple operation of the 245 it was easy enough to procedurally generate all 512 valid logic states which is what this program does.
I will add more chips as I get around to it but doing this procedurally gives me a ‘complete’ state map for a particular device.

Now, back to my first program. As anyone that visits this site will know I’m heavily into PAL chip dumping. Due to the way we ‘dump’ these PAL chips I end up with a binary files of all possible logic states for any given address. Using this binary file I can now create a state map for the tester so any compatible 20 pin PAL/GAL/PLS chip can be tested in circuit. Adding to the functionality of that it now also supports the 82S123 PROM. More devices will be supported as I get around to them as well.

I’ve spent a lot of time recently working on these files, much more time than i’ve spent actually troubleshooting with it but I think the end result will be worth it and hopefully everyone that uses one of these can benefit from it.
The files I create will be available from the relevant area in the downloads section once it has been created.

 Posted by at 2:14 pm

Truxton repair log

 PCB Repair Logs  Comments Off on Truxton repair log
Nov 062016
 

I got this Truxton PCB (export version of Tatsujin) in a recent operator raid:

100_9253

Once powered it up board showed GFX issue, the sprites were blocky :

Besides, there was some kind of video interference, this is a common issue on this board and usually it’s due capacitors in the audio section, indeed I found a 470uF 16V one with bad capacitance :

100_9275 Back to the sprites issue, relevant data are stored in four 1Mbit 28 pin MASK ROMs :

100_9257

I went to dump them and found a faulty one:

b65-04_bad

Replacing it with one from a donor board didn’t fix the issue therefore I went on in my troubleshooting.Each data bit of the sprites MASK ROMd is fed into inputs of four 8-bit 74LS166 register.I probed them with my logic comparator and led on output pin 13 lit for two of them:

100_9259

I desoldered the ICs:

100_9260

They both failed the out-out-circuit testing (obviously they were from Fujitsu) :

74ls16623a-24a

Sprites were fully restored :

100_9304

The last issue I had to fix was that Player 1 Start input didn’t work.The inputs circuitry was previously reworked by someone (note the replaced 74LS240 and some patched traces)

input_circuitry_reworked

I traced Player 1 Start back from pin 17 parts side of JAMMA connector to an end of a 220 Ohm resistor @R17 whose other end was tied to pin 13 of the 74SL240 @21K :

p1_start_tracing

Signal on pin 17 of the JAMMA connector and on first end of the resistor was high and correctly toggling when pressing the button while was totally missing on pin 13 of the 74LS240.Therefore the only culprit had to be the resistor.Indeed I got no reading measuring it on circuit:

100_9265

I removed  and tested the resistor out-of-circuit having confirm it was opened:

100_9269

100_9268

Job done.

 Posted by at 12:09 am

WWF Wrestlefest repair log

 PCB Repair Logs, Repair Logs  Comments Off on WWF Wrestlefest repair log
Oct 312016
 

When switching ON the game, sometimes it had very fast tempo music.

It happened 1 one out of 10 but it was very annoying.

So I used my frequency counter when it happened and I noticed that the 3.58mhz quartz ran at about 10.58mhz!

I changed it with a know good one but again it happened very often.

I was sure it was something connected to the quartz oscillator circuit and given that the resistances are difficult to be faulty I decided to change the cap C47  (33pF) with known good one.

After testing about 30 cycles of switching on and off the game didn’t develop again the problem

Game fixed.

 

wwf

Liquid Kids repair log

 PCB Repair Logs, Repair Logs  Comments Off on Liquid Kids repair log
Oct 312016
 

This game had two problem:

  • Glitchy and noisy sounds
  • Blocky background images

liquidk2

 

Given the high unreliablity of Taito maskroms I immediately tested the ones marked in red which with no surprice some pins not connected internally

 

liquidk

 

C49-04 restored the glitchy sound and C49-02 fixed the blocky gfx.

Replacements to be used are 27c400 (4mbit eproms with maskroms pinout)

Game 100% fixed

liquidk3