BryanMcPhail.com

Professional software development, amateur BMW tinkering, old arcade stuff

By

SNK Neo Geo 4 slot arcade pcb repair

This Neo Geo 4 slot motherboard reported ‘VRAM error’ on boot.  There is a useful diagnostic rom at http://smkdan.eludevisibility.org/neo/diag/ so I burned this to board to see if it gave more info.  Well.. not really, still a VRAM error at location 0000.

IMG_2420

Despite the popularity of these boards I couldn’t find a guide showing conclusively what each RAM chip is on the board, perhaps because they change about depending on the many different motherboard revisions.

IMG_2425

Eventually I worked out it was one of the top two surface mounted chips.  The VRAM attaches to the graphics custom chip, rather than the 68K cpu directly.  The error is a stuck data bit which is quite a rare error for a RAM – often this means a bad trace so I examined all the traces from the RAM to the custom chip and didn’t find anything.  The worst case is that the custom chip itself is bad.  As I didn’t yet really know which of the two RAMs was the upper (top 8 bits) or lower (bottom 8 bits, of which one was stuck) I desoldered them and swapped them.  The error moved from the lower RAM to the upper RAM which pretty much confirms a bad RAM chip rather than traces or custom chip.

IMG_2423

I removed a RAM chip from another broken NeoGeo and swapped it in.  All tests pass!

IMG_2426 IMG_2427

Added the 4 slot board back on top (the lower board can run on it’s own), all 4 slots and audio tested good.

IMG_2437 IMG_2435 IMG_2430

 

By

Data East Cobra Command arcade pcb repair

This turned out to be quite a complex fix…  Board booted to a black screen and made no sound, but a logic probe showed the data and address bus lines on the CPU and program ROM were all active, so the CPU was trying to do something at least.

There was obvious physical damage on the board in at least 3 places – a smashed custom resistor pack and gouged traces on the bottom of the board and on the top near the first program ROM.  I knew the resistor pack was used as the digital to analog convertor for one of the RGB channels, so although it would give bad colors, that shouldn’t stop the game running.  After checking and repairing the traces…  absolutely no change.

IMG_2445 IMG_2325

IMG_2329

My next theory was that the program RAM was bad and this was causing the CPU to crash.  I checked the program in the MAME debugger and it clears all memory before branching to a subroutine (with bad RAM a subroutine will mean a crash when the CPU stack is popped as the CPU will be given a bad return address).  This seemed to match the board behavior at least as the palette RAM was being cleared to all black.  But what RAM is the main CPU RAM?  This board has 11 RAM chips and no published schematics.  Usually the RAM next to the tilemap customs are for tilemaps, the RAM next to the sprite customs are for sprites, and the RAM next to the program ROMs is for the CPU.  So I pulled the RAM nearest the ROMs (H15) and it tested ok.  I then pulled the other RAM sitting on it’s own (B10) – that tested ok too.

Rather than risk damaging the board more by pulling all the RAMs (not to mention it would take ages) I took a different approach and wrote a little test program to see if the CPU was actually capable of running code. I modified the program ROM to print a string straight away, rather than clear memory and branch.  It worked!  So this proved the CPU, program, graphics was working to some degree, but didn’t explain why the correct program led to a black screen.  I worked out a more complex test program and wrote values to various RAM areas and read them back and printed on screen (again, taking care never to use the stack or call any subroutines as none of the RAM could be trusted).

IMG_2346

IMG_2355

Note there is no green in the images – I expected that from the bust resistor pack.  So the memory tests revealed that for every second byte the D0 value was stuck low (so writing 01 returns 00, writing 45 returns 44).  I used a logic probe on each RAM chip until I found the stuck data pin – turns out the main CPU ram is the pair at C10 and C11.  Removed this RAM chip – it tested bad, put in a replacement.. and still black screen.  I examined the traces on the board again and found another tiny break – all that work just to find a break near the others I already repaired (the pic is after I scraped it back more to repair it).

IMG_2358

Anyway…  game boots now!

IMG_2360

Graphics are clearly messed up and of course there’s still no green channel.  The broken resistor pack is a custom Data East pack used on many other games from this period.  I wasn’t worried about this too much as the worst case was I could just put in separate resistors to mimic the pack. I had a different plan in mind though – each resistor pack supports two channels, so with 4 channels available, and only 3 channels needed (red, green and blue) there had to be a spare… I traced out the TTL around the packs to find the unused channel, and just bridged one pack onto the other. Worked first time!

IMG_2441

IMG_2386

(The resistors values are fairly common at 220 Ohms, 470, 1000, 2200 to turn the 4 bit digital palette into an analog signal. The resistor pack contains a 5th value – 4800 Ohms but that is not used in this game).

On the home straight now – some corruption on the title screen and in-game.  This was quickly narrowed down to the tilemap ROMs in the corner of the board.  Removing them caused the corruption to go away (along with correct graphics too of course).  One ROM had obvious corrosion (EL07) but the ROM next to it was also bad (EL06).  I cleaned up the legs but the problem remained so it seems the problem was internal.  I replaced both with 27c512 eproms burned from the MAME set.

IMG_2362

And at last, game is perfect again!

IMG_2394

 

 

 

By

Taito Rastan arcade pcb repair

After working on pcbs with no self-tests for a while it was quite refreshing for this one to say exactly what was wrong with it – ‘COLOR RAM ERROR’.  The two color RAMs are located next to the PC040DA customs which are the digital to analog convertors for each of the RGB channels.  A logic probe showed that the lower RAM had stuck outputs.  Replaced this chip and the board was perfect.

Note that although the board has 2018-35 silkscreened on it (35ns response time RAM) the RAM installed was actually 45ns which works fine.

IMG_2200 IMG_2203

 

By

Data East Gate of Doom arcade pcb repair

Board initially seemed dead, no rgb video or sync output at all.  Logic probe showed that there was actually some CPU activity, but a lot of the graphics chips had no clock signal.

Attempt 1

Probing some TTL around the graphics crystal revealed a LS75 chip that seemed to have a stuck output.  This is a latch that outputs both Q and ‘not Q’ for input D.  The logic probe shows both D and Q pulsing, but ~Q was stuck low.  Replaced with another chip and it behaved exactly the same.  I have to assume ~Q is intentionally grounded out somewhere on the board and isn’t used.

IMG_2071IMG_2069

Attempt 2

I decided to trace out what controls the sync signal on the board.  The path runs from the edge connector to the diode at FB4, then the resistor at R13, then the LS04 chip @ L11.  The LS04 is used as a double invertor and the input comes from the custom graphics chip 55.

There are no schematics for Gate of Doom online, but there are for Desert Assault which is from the same era and also uses the 55 custom.  This shows the same setup with sync coming from pin 157 then a double inversion, so it seems to be the same design.  The schematics show the inputs to the custom – 14MHz clock to pin 11 – this was present and correct, reset on pin 15, again tested ok.  Various +5V lines also tested fine.  So unfortunately it seemed the custom chip was not working.

IMG_2076

Attempt 3

All of the other inputs to the graphics custom chip 55 come from the PAL’s on the board.  And they run hot – a couple quickly shooting up to 43C – so I decided to replace them all with GAL’s.  I didn’t really expect much from this, as the Data East PAL’s of this era often run very hot, and I’ve never seen a failed one.  Indeed this had no effect, but the GAL’s do run much cooler.

IMG_2081

Attempt 4

Examined the custom 55 again – applying some horizontal force to the pins revealed a handful of them moving – therefore not making good connection to the pads on the board.  Really I should have noticed this before, so I reflowed the solder with a hot iron on the pins to stick them to the pads again.  Success!  Everything now working 100%, including sound.  So even though the sync line was connected, some other control signals to the custom chip must have been disconnected.

IMG_2083 IMG_2092 IMG_2090 IMG_2085

 

 

By

Data East Crude Buster (Two Crude) arcade PCB repair

This is actually a pcb from the UKVac ‘Kent Raid’ (see https://arcadeblogger.com/2016/12/16/arcade-raid-cabs-found-in-kent-uk/), interesting to know the history of a pcb and this one sat abandoned for over 20 years.

IMG_1601

When powered on green garbage was displayed and that’s about it – no signs of life.  I tested the main RAM with a logic probe – the address pins were pulsing, as were the write enable and output enable pins, but the data lines remained stuck.  That’s a good sign the CPU is trying to do something but the RAM is dead – so I replaced the two chips (64K sram – TMM2063) with another two from a parts board.  Now I had some corrupt movement on screen, but it was also consistent corruption on every boot, so I was hopeful the game logic was actually running underneath the corruption.

IMG_1602IMG_1605

Probing some more RAM chips in the same way revealed two dead 16K sram chips – these are the red and blue palette RAMs – so replacing them game full colour corruption.  The audio CPU RAM appeared ok with the logic probe, but when I piggy-backed another 64K sram on top and hit the coin switch sound & music played, so I knew for sure the audio RAM was bad, but also the main CPU was running properly now.

Logic probe on the 4 ram chips near the custom tilemap asic showed address and data lines pulsing, but after removing them from the board they all tested bad.  At this point I had no 64K sram left so I removed 4 256K srams from a dead Run N Gun board and used them instead.  The pinouts between 64K and 256K are identical except for the extra 2 address lines – so as long as you make sure these lines are tied high or low it will work (I soldered little jumper wires onto the bottom of the board to tie the lines high).  Success – all tilemap graphics now working, but still no sprites.

With all the other bad RAM on the board, bad spriteram was likely – many Data East games actually have a setup where there are two copies of spriteram.  The main CPU writes to one set, then when complete sets a flag for hardware to copy it to the second set, that the sprite ASIC reads out of.  I assume the reason for this design was to avoid contention between the CPU writing and the ASIC reading the same memory.  All chips tested bad when removed from the board.  When replaced sprites came back, but were obviously corrupt.

IMG_1705 IMG_1721 IMG_1656

At this point I spent quite a lot of time triple checking all points I’d soldered on the new RAM, then checking for bad pins on the sprite ASIC, or any problems in the TTL that copies between the two spriterams.  It’s clear the player sprite was ‘almost’ correct, but had a corrupt layer on top of it. Eventually I unsoldered the large sprite mask ROMs to check if they were corrupt, but the checksums matched the MAME set.  When I booted the board with those ROMs missing though, the corrupt bit planes remained and suddenly it was clear what was going on.  The output enables for the second set of sprite roms were all stuck on – so whenever the main ROMs were active data from the second set was superimposed on top.  The custom sprite ASIC (chip 52) has a 32 bit combined data and address bus.  On one cycle it latches the desired address into external TTL, then on the next cycle it activates the sprite ROMs to read 32 bits of data.  The TTLs for the lower 16 address bits were fine, but the top 4 bits are controlled by a Fujitsu LS375N which had stuck outputs when tested with the logic probe.  This chip was replaced and all sprites were correct.

IMG_2069 IMG_1800 IMG_1797 IMG_1792

 

 

By

Technos WWF Superstars arcade PCB Repair

Two different boards, both very clean with no physical damage.  One booted to corruption, the other to a solid white screen.  Logic probe showed the outputs on the palette RAM were dead on the second board, so when replaced it also booted to corruption like the first one.

Piggy back on palette RAMIMG_1751

The logic probe seemed to the show the 68000 CPU was not getting a clock signal so I probed the chips near the crystal oscillator and removed them from the board with a heat gun for external testing (but they tested fine).  Strangely the game worked when I replaced the chip – that’s good but why?  I then also found the second board would sometimes boot if I flexed the PCB near the crystal.  My only theory is bad solder joints on the crystal that were fixed when the heat gun was used.  The second board also boots consistently after re-doing the solder around the crystal even though it looked fine.

IMG_1732 IMG_1747

So board 1 now works 100% with sound.  Board 2 boots but had some doubled up sprites at first (fixed by reseating the connectors between the two layers) and no sound.  The sound amp seems to be working, but at least one problem seems to be the YM3014 DAC chip.  The logic probe shows pulsing on the digital inputs, but the voltmeter shows no movement on the analog outputs (unlike the working board).  Right now I don’t have a spare to check.

IMG_1755 IMG_1759 IMG_1764

 

By

Atari Asteroids / Wells 19V2000 HV Diode

There’s a wealth of information on old black & white vector monitors on the internet, so when the picture on my Asteroids ‘bloomed’ up much larger than it should be and became unstable I quickly found tips suggesting the high voltage diode was at fault.  However.. most of this information was actually written in Usenet times – text only documents!  I couldn’t actually find a picture anywhere of where this diode is.

So for anyone else searching, I’ve circled it in red in the photo.  I used a diode marked ‘VARO H598′ bought from Ebay which is not the original part, but comes recommended as a replacement, and indeed it works perfectly.

I should also point out you should make sure the monitor CRT is fully discharged before going near this part as the high voltage can be present even when the monitor is powered off.  Info on that can be found elsewhere on the internet.

IMG_1269 IMG_1270 IMG_1272IMG_1291

 

 

By

Midnight Resistance arcade cabinet restore

Cab wasn’t terrible when I got it – two chunks of wood missing, lot of mold and dust, but the wood and vinyl fundamentally ok, so I decided to paint it rather than re-apply vinyl or laminate.

IMG_1417 IMG_1419

 

Tried out ‘wood’ Bondo rather than regular Bondo to patch up scuffs and missing pieces.  I used some spare t-molding as a guide to fill the missing chunk at the control panel, worked out quite well.  Also filled in the holes from those big ugly lock bars, not putting them back on.

IMG_1503 IMG_1502

Some painting, then sanding, then more painting..  Plus new t-molding all-around, and replaced faded marquee with a reproduction.

IMG_1568

I swapped out the plain joystick tops with some burn marks for some Data East logo tops I’ve had sitting around for a while.  They aren’t perfect but better.

IMG_1590

Reproduction control panel overlay added and NOS side-art that I’ve been hoarding for a while.  Original bezel remains even though it has some stains and a rip.  Might change it out later.

IMG_1591 IMG_1569

Coin door was fully disassembled, some rust cleaned up, repainted and new locks added.

IMG_1831

End result!  It’s not a 10/10 maybe an 8 out of 10, but good enough :)

IMG_1842

 

By

Capcom Gun.Smoke PCB repair

This is a bootleg PCB though a well made one with excellent image quality.  The problem is that the buildings have corrupt colours.  This is a rather strange fault as Gun.Smoke only has 1 layer of tiled graphics and all of the other tiles were fine.  This rules out almost all potential RAM or TTL faults (maybe with the exception of some of the palette circuitry), as those components are clearly working fine with the other tiles.  From the look of the graphics I suspected a couple of bit-planes for the tiles had disappeared – because each tile only has 4 colours per block, instead of 16.  MAME confirmed the tile ROMs were laid out as 4 pairs with each ROM contributing 2bpp and the corrupt buildings were within the first pair.

IMG_0864IMG_08642

The missing 2bpp theory was confirmed when I ran the board with ROM ’13′ removed – the buildings completely disappeared – so this means that ’13′ was working and it’s partner ’9′ wasn’t contributing anything.  However all ROMS read ok in the reader and matched the MAME set exactly.  The logic probe lit up for all pins on ROM ’9′ so the socket seemed good.  Next theory was the chip enable (/CE) logic was faulty and ROM ’9′ was not being asked to output any data.  However examination of the traces showed /CE was linked for each pair of ROMs in the set (as they always output at once to give make 4bpp output) so could not be that.

IMG_0884

I then burned a new eprom with ROM ’9′ data from MAME, placed it on the board and everything worked!  So the fault was definitely with the ROM even though it read fine on PC.  The only theory I have is that the original ROM ’9′ is more susceptible to low voltage than the others.  There is quite a bit of voltage drop from the +5V on the main board to the video board.

IMG_0892

By

Time Soldiers arcade PCB repair

Bought as a non-working board for $9.99 – the most obvious problem is that no CPU was present so clearly the game wasn’t going to do much without that!  With a replacement 68000 in hand (again from Ebay for only a few $) the game booted to garbage.

IMG_1286   IMG_1285

A logic probe on the CPU address and data lines showed zero activity, so the CPU clearly wasn’t doing anything.  Power and ground tested as good.  The reset and halt lines on the CPU were pulsing, so it seemed something on the board was trying to kick the CPU into life.  Testing the CLK pin on the 68000 showed it to be stuck low.  I traced out where this pin went and it connects to the output (Q) of a LS74 next to the oscillator.   The logic probe seemed to show this chip had failed, as a CLK was pulsing on the LS74 input, but the outputs remained stuck (one output feeds back into a LS74 input, so the output should toggle hi/lo every clock in order to form the 68K clock).

Tested off-board – failed – replacement from Dragonninja parts board soldered in – board boots right up!  Quickest TTL level fix I’ve ever done.

IMG_1290 IMG_1293 IMG_1289

At first I thought there was a graphics problem as the title screen was corrupt – though it’s strange all of the other screens were perfect.  Then I remembered I’d seen this a long time ago in MAME..  If you boot the English language ROMs with the Japanese dipswitch enabled the title screen is corrupt (because it expects the Japanese character ROMs).

Unfortunately this board is stuck in Japanese – because the dip-switch isn’t being read by the software.  A previous owner has removed resistor packs for the dip and the jamma inputs, presumably to repair something else!

That shouldn’t be too hard a fix – to be continued.

IMG_1287