BryanMcPhail.com

Professional software development, amateur BMW tinkering, old arcade stuff

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

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>