repair log – Page 4 – JAMMArcade.net

Star Jacker repair log

Aug 302014

Got a mammoth box of boards from Ben76 the other day. This Star Jacker PCB is one of them.
Game gave a black screen when powered up and there was no sync signal.
Ben also gave me a scan of the schematics for this board so was quickly able to determine where the sync came from.
My heart sank a little bit as the sync comes from a PAL16R4 chip

On investigating I found the VCC pin was not making a good contact in the socket so I removed both of the PAL sockets and replaced them.

So booting now gave me sync but solid white screen. Ive seen this before on quite a few boards and its almost been RAM issues. I started probing the RAM chips and found a 2016 SRAM at location IC151 had completely dead outputs despite being enabled and having active inputs. I desoldered it and replaced it with a 6116 SRAM chip.

Now I get this (NOTE: the red colour is actually present but I have to edit my pictures these days as the HTC One makes low light pictures all purple)

All fully working again.

Circus Charlie repair log

PCB Repair Logs, Repair Logs 3 Responses »

Aug 272014

Game was dead on power up.
Pressing down on the crystal brought clocks back. Resoldering the crystal didn’t help so there must have been a break internal to the unit. I ordered a spare 18.432MHz crystal oscillator and waited for it to arrive.

The new crystal arrived and fitting it brought the main clock back however my monitor screamed at me.
Checking the output from the 082 custom chip on the scope revealed that the SYNC signal was around 24kHz.

I originally thought the 082 was at fault as id seen so many of them go wrong before but after sleeping on it I started to think this unlikely. At this point I asked for a bit of help from forum user cmonkey. He knows a lot about Konami hardware and has provided a lot of insight to me in the past.
He very generously took some measurements off his Gyruss PCB and it confirmed that the clock input going to the 082 was too high on my board. It should be 6.14MHz into pin 13 and I was getting around 9.14MHz.

At this point I thought I would do a bit of circuit simulation and drew out the clock generation circuit in PSpice.

This is how the circuit should be.

As you can see from the simulation I have around 6MHz.
Probing around this PCB however revealed that pin 1 of the 74LS107 was dead. Removing this line from the simulation revealed this:

Exactly what I was wanting to see.
I removed the LS107 and tested it. It failed as expected.

I found one on a scrap board. This brought everything back to life.

Powering the board up initially gave me a static screen of 0’s. This is what you normally see during the start of the POST. Ill get back to this issue later.
Powering down and back up again gave me this:

Using MAME I confirmed the Video RAM area was to blame.
Checking the address lines on the 8128 RAM at location 3E revealed 4 dead lines. I traced these back to 74LS157 at location 5E. Replacing this brought back the graphics.

There is still a small graphics issue at this point which I struggled to find and also the intermittent power up problem I mentioned earlier so thought I would move on to the other issue of the controls not working.

Neither of the coin inputs work.
Back to the schematics, I can see where the signal comes in and taking some measurements shows there is something wrong as I’m getting around 1v at pin 6 of the chip at 3F.
There is very little to this part of the circuit and the resistor array looked good so I desoldered the 74LS253 and it failed all tests. Replacing this brought the controls back.

So back to my remaining problems.
First, the graphics issue. Its hard to describe but on the parts of the screen where the coloured dots cycle round this also affected half of the 8×8 tile above it.

As it only affected half the tile I eventually came to the conclusion it was a timing issue. This led me right back to the beginning where the reset circuit lies.
The power on reset is generated by a 555 timer which goes through a bit of logic and eventually out to the rest of the board as a /RES signal.

This signal comes out on pin 8 of a 74LS08 AND gate. Working back I found I had no output on pin 11 at all. I desoldered this chip and replaced it.

It fixed the reset problem but also fixed the graphics problems too

I guess it could have been caused by a timing issue after all?

This board looked is VERY good condition and, looking at the edge connector, it cant have been powered up more than a handful of times so its interesting to see that all these problems were present.
Very pleased I got this fixed.

X Multiply repair log #3

PCB Repair Logs, Repair Logs Comments Off

Aug 112014

Yes, again.
During some playing of this recently repaired board the game froze up.
On reset I was greeted with this static screen.

Non booting boards are generally quite easy to fault find but due to the V30 I was having problems. This is when I came across a post on KLOV from some time ago with someone asking if an 8086 Fluke POD could be used to test a V30 based system. The general thinking was that it could but no one ever tried it, until now!
Im pleased to say it does work (excluding the RUN UUT function).

Very quickly I found that the main ROM’s could not be read properly. The correct signature was 6A03 and I was getting 6935.
Following my schematics I found that there is a 74LS373 at location IC51 that is used as the latch to address the ROM’s.

This input was confirmed good but there was a stuck bit on the output.
I replaced this and the game was back once again. Ive left this soak testing and hopefully it will be rock solid now.

So just to confirm. The 8086 pod for a Fluke 9010/9100 can be used to check V30 based systems.

X Multiply repair log #2

PCB Repair Logs, Repair Logs 2 Responses »

Jul 262014

I recently sold this PCB but after a week I was told the board had developed a fault.
The fault showed up as “RAM NG 10” at boot-up and there was some issues with the sprites.

There is absolutely no logical meaning to the error message so using MAME I started corrupting different RAM values during it POST to see what RAM errors were flagged up during which memory writes.
Originally I couldn’t understand how the awful V30 CPU worked. Without knowing how it worked I was unable to use the MAME debugger effectively. Charles MacDonald came to my rescue and told me how the V30 addresses were set. Thanks very much to Charles.
You can see the outcome of that exercise in THIS previous post.

So now I knew for sure that the fault was with the sprite RAM. Now the next challenge, which RAM chip is the sprite RAM?
I originally tried shorting some address/data lines on RAM chips to see if any other errors were flagged but strangely it didn’t show anything else at all.
With nothing left to try I started making my own schematics up in the hope I could work out which RAM was responsible for the sprites.

Due to the complex nature of this board set, I was stuck for quite some time looking on the lower video PCB assuming (yes I know) that this is where the sprite RAM could be but was unable to find any problems at all.
Taking a step back I reversed the PAL chip XM_A-7D- into equations. Using these equations and the schematics I had drawn up I could take an educated guess as to what RAM chip was the sprite RAM.
Knowing that the sprite RAM lies at address 0xc0000, this means that address pins A19 & A18 would need to be active. Looking at the equations I could see that output pin 17 of the PAL chip would fit this address so I followed the signal which led to the /CE line of a 74LS245 of IC40 on the top CPU PCB.

The only chip that this chip goes to is a 2018 RAM chip at location IC52.
This was pretty good news. I removed the chip and it failed the tests so I replaced it and now all the POST tests pass.
The sprites are all back to how they should be too.

Ill be keeping hold of this board I think. It was one of the first games I ever bought since getting into this hobby so it will stay with me for good now.

Juno First repair log #3

PCB Repair Logs, Repair Logs Comments Off

Jun 262014

Third repair log from the batch of Juno First boards.
On power up the board was completely dead. No clocks were present on the CPU or many other IC’s.
As this is a bootleg board the available schematics do not fully apply and the clock circuit is normally handled by custom chips so this was a bit of a learning experience.
To help in dealing with this problem I started making my own schematics up.

Using a logic probe I could see that the outputs of the 74LS161 @ H14 were all HIGH. As there is no clock present to this chip it should not have counted anything at this point and they should all be LOW. This meant to the board was booting up in an incorrect state and the clock circuit was never starting.
I desoldered and replaced the offending 161 chip.

The clocks were now all present but I just got a static blue screen and the watchdog was constantly resetting the system.
Using my in circuit Arduino tester I knew the ROMs could all be read correctly by the CPU. I also knew all the program RAMs were fine.
Replacing the 6809 CPU allowed the game to boot properly.

Next problem was the sound or lack of it.
The sound CPU is a good old Z80 so I fitted the Fluke and did a ROM check. This reported back an incorrect signature and when I removed the ROM I see this

The VCC pin was missing. I soldered a new pin onto this and this board is fully fixed.

The last bootleg board has been a major pain and at this point in time I have admitted defeat with it. I have also been harvesting parts from it to fix the others so it will be written off.

Older Entries Newer Entries