Professional software development, amateur BMW tinkering, old arcade game stuff


EPOS The Glob / Beastie Feastie / Eeekk! hardware encryption

The EPOS games Glob, Super Glob, Beastie Feastie and Eeekk! run on Pacman hardware with a custom daughterboard. They use an obfuscated security system to prevent swapping the games just by burning the ROMs. Although these games are all emulated in MAME the security PAL chip for Beastie Feastie was not dumped until recently which meant the games couldn’t be repaired on real hardware until then (Although MAME had dumps for the PALs, they are all confirmed bad and did not work on real boards). The Eeekk! board is very rare and can not be found to be dumped, so I was asked if it’s possible to recreate the Eeeek! PAL based on the Beastie Feastie PAL and MAME information. And after some thought, yes…! Let’s see how.. this will get pretty technical though…



    Part 1

First let’s look at the equations that come from the Beastie Feastie .JED file. ‘o’ means output (o19 = pin 19 on the PAL used for output). ‘i’ means input (i4 = pin 4 on the PAL used for input). / means invert/negate. * means AND. + means OR. Rather confusingly pin 11 is a double negative – it’s negated in the input section /i11=11 and negated everywhere it’s used in the equations.

i1=1 i2=2 i3=3 i4=4 i5=5 i6=6 i7=7 i8=8 i9=9 GND=10 /i11=11 o12=12
o13=13 o14=14 o15=15 o16=16 o17=17 o18=18 o19=19 VCC=20

o19 = /i4 * /i7 * /i9 * /i11
+ /i5 * i7 * /i9 * /i11
o18 = /i1 * /i8 * /i9 * /i11
+ /i6 * i8 * /i9 * /i11
o17 = i6 * /i8 * /i9 * /i11
+ /i3 * i8 * /i9 * /i11
o16 = /i2 * /i7 * /i9 * /i11
+ i4 * i7 * /i9 * /i11
o15 = /i3 * /i8 * /i9 * /i11
+ i1 * i8 * /i9 * /i11
o14 = i5 * /i7 * /i9 * /i11
+ /i2 * i7 * /i9 * /i11
/o13 = i9 * /i11
o12 = /i9 * /i11

And the physical connections to the encryption PAL on the board:

PAL10H8 inputs

1: D7 from encrypted program ROM
2: D6 from encrypted program ROM
3: D4 from encrypted program ROM
4: D3 from encrypted program ROM
5: D1 from encrypted program ROM
6: D0 from encrypted program ROM

7: LS193 Q0
8: LS193 Q1
9: LS193 Q2
11: LS193 Q3

The LS193 is a 4 bit counter, that can provide a 4 bit (16 states) encryption key to the PAL. The program code can modify the counter state, which means the encryption can change dynamically as the program executes! In theory this means the program could be impossible to statically decrypt and run in the same amount of ROM as it can ‘read itself’ and each byte would have 16 permutations the code could rely on (in practice we’ll see later only 4 permutations are used). This is an interesting aspect to the original security – as to statically decrypt the 4 (or 16) states would mean using 4 or 16 times as many ROMs which would have been cost prohibitive for a commericial pirate.

Most of the outputs go to a LS244 buffer chip that passes through to the Z80 CPU.

19: o19 -> LS244 1A1 -> 1Y1 -> D7 Z80
17: o17 -> LS244 1A2 -> 1Y2 -> D5 Z80
15: o15 -> LS244 1A3 -> 1Y3 -> D3 Z80
14: o14 -> LS244 2A2 -> 2Y2 -> D2 Z80
16: o16 -> LS244 2A3 -> 2Y3 -> D4 Z80
18: o18 -> LS244 2A4 -> 2Y4 -> D6 Z80
12: o12 -> LS10 pin 1 (3 input NAND)
13: o13 -> LS10 pin 2 (3 input NAND)

So 6 of the 8 bits are decrypted by the PAL, and 2 of the bits go directly via a LS04 invertor. Outputs 12 & 13 seem to be involved in program ROM enable*, they are not involved in encryption and must be the same between all games for the enable circuit to work, so we don’t need to worry about them. (*Update from HudsonArcade – these drive the LS244 enables, the ROM select is just regular A13 from the CPU. Thanks!).

Let’s look at things from the LS244 point of view

PAL o19 -> 1A1 -> 1Y1 -> D7 Z80
PAL o17 -> 1A2 -> 1Y2 -> D5 Z80
PAL o15 -> 1A3 -> 1Y3 -> D3 Z80
(LS04 12) -> 1Y4 -> D1 Z80
(LS04 10) -> 2Y1 -> D0 Z80
PAL o14 -> 2A2 -> 2Y2 -> D2 Z80
PAL o16 -> 2A3 -> 2Y3 -> D4 Z80
PAL o18 -> 2A4 -> 2Y4 -> D6 Z80

We can rewrite the equations substituting the Z80 data lines and the key lines. I’ll also switch to use ‘C’ terminology (&& for and, || for OR, ! for negate), as I think in C++…

o14 = (D1 && !KEY0 && !KEY2 && !KEY3) || (!D6 && KEY0 && !KEY2 && !KEY3)
o15 = (!D4 && !KEY1 && !KEY2 && !KEY3) || (D7 && KEY1 && !KEY2 && !KEY3)
o16 = (!D6 && !KEY0 && !KEY2 && !KEY3) || (D3 && KEY0 && !KEY2 && !KEY3)
o17 = (D0 && !KEY1 && !KEY2 && !KEY3) || (!D4 && KEY1 && !KEY2 && !KEY3)
o18 = (!D7 && !KEY1 && !KEY2 && !KEY3) || (!D0 && KEY1 && !KEY2 && !KEY3)
o19 = (!D3 && !KEY0 && !KEY2 && !KEY3) || (!D1 && KEY0 && !KEY2 && !KEY3)

If we remove the key bits we can see each output bit depends on two input bits

o14 = D1 || !D6
o15 = !D4 || D7
o16 = !D6 || D3
o17 = D0 || !D4
o18 = !D7 || !D0
o19 = !D3 || !D1

And let’s rewrite the equations another way to show what ROM bits attach to what Z80 bits.

Z80 D0 comes from LS04 pin 12
Z80 D1 comes from LS04 pin 10
Z80 D2 must be D1 or !D6 from the ROM (o14 in PAL)
Z80 D3 must be !D4 or D7 from the ROM
Z80 D4 must be !D6 or D3
Z80 D5 must be D0 or !D4
Z80 D6 must be !D7 or !D0
Z80 D7 must be !D3 or !D1

    Part 2

Let’s reconcile this with MAME source. machine/epos.cpp

MACHINE_START_MEMBER(pacman_state, theglobp)
/* Note: D2 is inverted and connected to D1, D5 is inverted and
connected to D0. The other six data bits are converted by a
PAL10H8 driven by the counter. */

This matches so far – D0 and D1 are noted to be inversions (LS04) of D2 and D5 from ROM data. D2 and D5 aren’t used by the PAL. The counter is the LS193 chip that supplies a 4 bit input to the PAL.

/* While the PAL supports up to 16 decryption methods, only four
are actually used in the PAL. Therefore, we'll take a little
memory overhead and decrypt the ROMs using each method in advance. */

MAME notes that although the counter can supply 16 states (4 bits) only 4 states are used by the games, corresponding to counter states 0×8, 0×9, 0xa, 0xb

MAME lists the bit swizzle order for the 4 states as:

{ 3,7,0,6,4,1,2,5 },
{ 1,7,0,3,4,6,2,5 },
{ 3,0,4,6,7,1,2,5 },
{ 1,0,4,3,7,6,2,5 },

although confusingly this table is ‘backwards’ with D7 first and D0 last (so the 5 at the end of the row refers to D5 connecting to D0, the 2 second most from right refers to ‘D2 inverted and connected to D1′). If we can scan the columns we can see that each bit can only have 1 or 2 input bits (the first column is 3 or 1, the second column is 7 or 0). Now we can confirm MAME data matches the PAL equations if we refer back to the Z80 form equations:

The first column (D7) uses only bits 1 or 3 which matches ‘Z80 D7 must be !D3 or !D1′
The second column (D6) uses only bits 7 or 0 which matches ‘Z80 D6 must be !D7 or !D0′
The third column (D5) uses only bits 0 or 4 which matches ‘Z80 D5 must be D0 or !D4′

Looking at the equations again, every output contains depends on 3 of the 4 input keys. And the 3rd and 4th input key is identical between all outputs, so we can pretty much ignore it and say each output only depends on 2 input keys. This is where the 4 states in MAME come from.

Let’s work through state 0×8 which MAME notes uses this bit swizzle order – { 3,7,0,6,4,1,2,5 } and inversion (XOR) of 0xfc. Encryption state 0×8 means the key is:

KEY0 = 0 (low / false)
KEY1 = 0 (low / false)
KEY2 = 0 (low / false)
KEY3 = 1 (high / true) (remember key input i11 has a double negation from part 1!)

Rewrite the Z80 equation for D2 with this set of input keys:

Z80 D2 IN = (D1 && !KEY0 && !KEY2 && !!KEY3) || (!D6 && KEY0 && !KEY2 && !!KEY3)
Z80 D2 IN = (D1 && !0 && !0 && !!0) || (!D6 && 0 && !0 && !!0)
Z80 D2 IN = (D1 && 1 && 1 && 1) || (!D6 && 0 && 1 && 1)
Z80 D2 IN = (D1 && 1 && 1 && 1)
Z80 D2 IN = (D1)

So D2 at the Z80 is D1 from the encrypted ROM with no inversion

When the key state is 0xb:

KEY0 = 1
KEY1 = 1
KEY2 = 0
KEY3 = 1

Z80 D2 IN = (D1 && !KEY0 && !KEY2 && !!KEY3) || (!D6 && KEY0 && !KEY2 && !!KEY3)
Z80 D2 IN = (D1 && !1 && !0 && !!0) || (!D6 && 1 && !0 && !!0)
Z80 D2 IN = (D1 && 0 && 1 && 1) || (!D6 && 1 && 1 && 1)
Z80 D2 IN = (!D6 && 1 && 1 && 1)
Z80 D2 IN = !D6

So D2 is inverted D6 for this key.

So this matches the table in MAME (the 3rd column from the right being D2 and it contains the values 1 and 6). The MAME xor key is used to mask the inversions.

All of the 6 input bits can be solved for all 4 keys in the same way. And KEY2 and KEY3 can effectively be ignored as they are constant in all equations.

    Part 3

Now we can attempt to build the Eeek equations based on MAME knowledge. The 4 swizzle tables are:

    { 7,6,1,3,0,4,2,5 },
    { 7,1,4,3,0,6,2,5 },
    { 7,6,1,0,3,4,2,5 },
    { 7,1,4,0,3,6,2,5 },

So we can break this down by walking the columns:

    Z80 D7 can only ever come from ROM D7
    Z80 D6 can only ever come from ROM D6 or D1
    Z80 D5 can only ever come from ROM D1 or D4
    Z80 D4 can only ever come from ROM D3 or D0
    Z80 D3 can only ever come from ROM D0 or D3
    Z80 D2 can only ever come from ROM D4 or D6
    Z80 D0 can only ever come from ROM D2
    Z80 D1 can only ever come from ROM D5

Based on the Beastie Feastie knowledge, we can work out what keys influence what bits.

    Z80 D7 is constant – does not care what key 0 or key 1 is.
    Z80 D6 depends on key 0, does not care what key 1 is
    Z80 D5 depends on key 0, does not care what key 1 is
    Z80 D4 depends on key 1, does not care what key 0 is
    Z80 D3 depends on key 1, does not care what key 0 is
    Z80 D2 depends on key 0, does not care what key 1 is
    Z80 D1 is constant – does not care what key 0 or key 1 is.
    Z80 D0 is constant – does not care what key 0 or key 1 is.

Put these things together, and add in the constant KEY2 and KEY3 terms (though the game will surely work if we just emit them).

    Z80 D7 = (D7 && !KEY2 && !KEY3)
    Z80 D6 = (D6 && !KEY0 && !KEY2 && !KEY3) || (D1 && KEY0 && !KEY2 && !KEY3)
    Z80 D5 = (D1 && !KEY0 && !KEY2 && !KEY3) || (D4 && KEY0 && !KEY2 && !KEY3)
    Z80 D4 = (D3 && !KEY1 && !KEY2 && !KEY3) || (D0 && KEY1 && !KEY2 && !KEY3)
    Z80 D3 = (D0 && !KEY1 && !KEY2 && !KEY3) || (D3 && KEY1 && !KEY2 && !KEY3)
    Z80 D2 = (D4 && !KEY0 && !KEY2 && !KEY3) || (D6 && KEY0 && !KEY2 && !KEY3)
    Z80 D1 = (D2 && !KEY2 && !KEY3)
    Z80 D0 = (D5 && !KEY2 && !KEY3)

Now we have apply the inversion terms which MAME lists in hex for the 4 tables, but are easier to understand in binary:

    key 0 – 0xfd = 1111 1101
    key 1 – 0xbf = 1011 1111
    key 2 – 0×75 = 0111 0101
    key 3 – 0×37 = 0011 0111

So D7 is inverted in key states 0 and 1, and non-inverted in 2 & 3. D6 is inverted in key states 0 and 2, non-inverted in 1 & 3. So if we walk the columns we can say:

    D7 inversion depends on key 1
    D6 inversion depends on key 0
    D5 inversion is constant (same for all key states)
    D4 inversion is constant (same for all key states)
    D3 inversion depends on key 1
    D2 inversion is constant (same for all key states)
    D1 inversion depends on key 0
    D0 inversion is constant (same for all key states)

As a sanity check we can see that where there is a key dependency it matches the key influence above.

Rewrite the equations to add inversions:

    Z80 D7 = (!D7 && !KEY1 && !KEY2 && !KEY3) || ( D7 && KEY1 && !KEY2 && !KEY3)
    Z80 D6 = (!D6 && !KEY0 && !KEY2 && !KEY3) || (!D1 && KEY0 && !KEY2 && !KEY3)
    Z80 D5 = ( D1 && !KEY0 && !KEY2 && !KEY3) || (!D4 && KEY0 && !KEY2 && !KEY3)
    Z80 D4 = (!D3 && !KEY1 && !KEY2 && !KEY3) || (!D0 && KEY1 && !KEY2 && !KEY3)
    Z80 D3 = (!D0 && !KEY1 && !KEY2 && !KEY3) || ( D3 && KEY1 && !KEY2 && !KEY3)
    Z80 D2 = (!D4 && !KEY0 && !KEY2 && !KEY3) || ( D6 && KEY0 && !KEY2 && !KEY3)
    Z80 D1 = (!D2 && !KEY2 && !KEY3)
    Z80 D0 = (!D5 && !KEY2 && !KEY3)

Now rewrite back to the PAL’s point of view rather than the Z80, so D7 is PAL o19, D5 is pal o17, etc

    PAL o19 = (!D7 && !KEY1 && !KEY2 && !KEY3) || ( D7 && KEY1 && !KEY2 && !KEY3)
    PAL o18 = (!D6 && !KEY0 && !KEY2 && !KEY3) || (!D1 && KEY0 && !KEY2 && !KEY3)
    PAL o17 = ( D1 && !KEY0 && !KEY2 && !KEY3) || (!D4 && KEY0 && !KEY2 && !KEY3)
    PAL o16 = (!D3 && !KEY1 && !KEY2 && !KEY3) || (!D0 && KEY1 && !KEY2 && !KEY3)
    PAL o15 = (!D0 && !KEY1 && !KEY2 && !KEY3) || ( D3 && KEY1 && !KEY2 && !KEY3)
    PAL o14 = (!D4 && !KEY0 && !KEY2 && !KEY3) || ( D6 && KEY0 && !KEY2 && !KEY3)

D0 and D1 are not affected by the PAL, so we can ignore them.

Rewrite back to the JED format we can use with the hardware, with the mapping from before:

    i1: D7 from ROM
    i2: D6 from ROM
    i3: D4 from ROM
    i4: D3 from ROM
    i5: D1 from ROM
    i6: D0 from ROM

    i7: LS193 Q0 / Key 0
    i8: LS193 Q1 / Key 1
    i9: LS193 Q2 / Key 2
    i11: LS193 Q3 / Key 3

    o19 = /i1 * /i8 * /i9 * /i11
    + i1 * i8 * /i9 * /i11
    o18 = /i2 * /i7 * /i9 * /i11
    + /i5 * i7 * /i9 * /i11
    o17 = i5 * /i7 * /i9 * /i11
    + /i3 * i7 * /i9 * /i11
    o16 = /i4 * /i8 * /i9 * /i11
    + /i6 * i8 * /i9 * /i11
    o15 = /i6 * /i8 * /i9 * /i11
    + i4 * i8 * /i9 * /i11
    o14 = /i3 * /i7 * /i9 * /i11
    + i2 * i7 * /i9 * /i11
    /o13 = i9 * /i11
    o12 = /i9 * /i11

o12 and o13 we’ll leave alone as they aren’t involved in encryption and must be the same between all games.

Part 4

    The final EQN file – this can be burned to a GAL16V8 and used on the original hardware. The 4 jumpers on the board must also be set to match the game. The 4 jumpers actually correspond to the default key the game boots in (from the 0×8, 0×9, 0xa, 0xb) counter states. Glob boots in state 0xa (top to bottom jumpers on, off, on, off) whilst Eeekk boots in state 0×9 (off, on, on, off)

    ; JED2EQN -- JEDEC file to Boolean Equations disassembler (Version V063)
    ; Copyright (c) National Semiconductor Corporation 1990-1993
    ; Disassembled from BEASTIE.JED. Date: 1-5-123

    chip EEEK GAL16V8

    i1=1 i2=2 i3=3 i4=4 i5=5 i6=6 i7=7 i8=8 i9=9 GND=10 /i11=11 o12=12
    o13=13 o14=14 o15=15 o16=16 o17=17 o18=18 o19=19 VCC=20

    @ues 0000000000000000
    @ptd unused


    o19 = /i1 * /i8 * /i9 * /i11
    + i1 * i8 * /i9 * /i11
    o18 = /i2 * /i7 * /i9 * /i11
    + /i5 * i7 * /i9 * /i11
    o17 = i5 * /i7 * /i9 * /i11
    + /i3 * i7 * /i9 * /i11
    o16 = /i4 * /i8 * /i9 * /i11
    + /i6 * i8 * /i9 * /i11
    o15 = /i6 * /i8 * /i9 * /i11
    + i4 * i8 * /i9 * /i11
    o14 = /i3 * /i7 * /i9 * /i11
    + i2 * i7 * /i9 * /i11
    /o13 = i9 * /i11
    o12 = /i9 * /i11

    eeekkPCB (1)


    Click for Eeekk! jed download (zipped)


Konami Pandora’s Palace arcade pcb repair

Board 1

Board would boot with some corrupt text, then reset.  The tilemap RAM for text tested ok, but it was just re-seating and cleaning the tilemap custom 85 that fixed the text which now read CPU A OK.  At this point CPU B is meant to kick in and run it’s own self test and report, but the board kept resetting.  A logic probe on CPU B reset line showed it pulsed very briefly then went back to being held in reset, so it didn’t have a chance to run the self test.

20200626_192333  20200626_193346

Things got a bit trickier at this point – the reset is controlled by a LS138 and LS259 that the main CPU can write to.  These components were removed and replaced with no change, so I fired up MAME to debug what exactly happens during the boot sequence.  It turns out both CPUs can write to the LS259 latch – CPU A performs it’s self test, enables CPU B and then sits in a tight loop until CPU B finishes and enables interrupts on CPU A at which point they both run in parallel.


This raises the possibility that CPU B was actually resetting itself with a rogue write to the latch and causing a deadlock…  And indeed that was the problem, a corrupt program that had tested fine first time around but on a re-read showed some random bad bits.

The game now played with some bad sprites – other sprites were fine though, so the sprite custom chip and RAM were likely good.  Again, this was just failed eproms that needed replaced.


Finally, lack of sound was a failed Z80 CPU on the top board – a logic probe showed it had a valid clock, reset and so on but all data and address lines were stuck high.  Putting in a fresh CPU fixed everything.


Board 2

Did not boot at all with garbage on screen and the CPU stuck in a watchdog reset.  This turned out to be straightforward as the CPU A boot eprom had completely failed.  Replacing it enabled the game to run, with some bad sprites, but like the first board this was just more failed eproms.

20200627_083257 20200627_125047


Konami X-Men arcade pcb repair #2

Game played and passed all self tests (including mask ROM tests) but some background elements had incorrect colors or appeared completely black.  Colors ultimately come from the palette RAM but that was most likely good as the self test had passed.  A group of 3 LS157 chips arbitrate access to the palette RAM address lines – these can be controlled either by the main CPU, or by the 053251 priority mixer which combines all of the layers (sprites and tilemaps) to send a final output pixel to the palette lookup.

20200619_193126 20200619_193430

All address lines seemed good with a logic probe so the problem was most likely the 053251 itself or the tilemap custom that fed it.  As other tilemap elements were fine, the 053251 was replaced with one from a scrap board and this fixed the problem.

20200620_083111 20200620_094439


Konami Hyper Sports arcade pcb repair #2

The game logic seemed to be running but graphics were totally corrupted.  Tilemaps are usually easier to fix than sprite problems so I started there, but the relevant custom chips and RAM checked out fine.  The breakthrough came when I noticed one of the RAM chips never had the write (/W) line enabled at any point.  The write lines should almost always be pulsing on this game as the CPU writes tile data into RAM.


The V1DIR and V2DIR signals actually start on the top CPU board, but they travel to the bottom and are buffered by an LS241 before reaching the RAM chips.  This chip was removed and tested bad before being replaced.

hyper  20200624_090256

Which improved things somewhat – definitely recognisable now but still broken.


I kept on debugging the tilemap RAM and found a couple of data lines were always high – I knew the RAM was good so I started to search for ways in which the data could be corrupted before getting to the RAM.  This traced back to the LS245 on the top CPU board that sends CPU data to the video board – it had failed on multiple lines so literally every byte the video board received was corrupt in some way.  Replacing this fixed everything 100%.

20200624_151354 20200624_152505 20200624_152517



Taito Legend of Kage arcade pcb repair #2

Game just booted to a solid white screen with the CPU in a watchdog reset loop.  This game, like Bubble Bobble, uses custom package RGB DAC’s that are known to fail (and also need +12V and -5V connected to work) but it seemed the palette RAM was actually passing full white to the DACs so the initial problem wasn’t there.

Usual test first is to check the program ROMs – and one wouldn’t read at all due to some kind of internal short.  When replaced the game ran, but without any sprites or tilemaps but at least it proved the RGB customs were working.


RAM on the video board all tested fine, but what looked like some dirt on the board actually turned out to be a massive gouge that had broken 10-12 traces.  When patched back up the game was fine.

20200619_173316 20200619_171604 20200619_191755


Taito Frontline arcade pcb repair #2

Game played but without sound.  Diagnosing sound problems on these boards is pretty easy as all of the sound generators have test points on the top board – PSG1-4, DAOUT.  Attaching power speakers here lets you hear the individual sound outputs before they are mixed.  If they are all silent then there is most likely a sound CPU problem, but for this board everything sounded great at the test points.   The sound is then mixed and sent to the two volume controls – powered speakers can also be attached directly to the right-most and center pins of the volume pots to check audio post mix.  From there it’s almost straight to the power amp, and if you can hear audio over powered speakers attached to the power amp input (pin 1) then almost certainly the power amp is dead (or is missing +12V).  In this case the MB3730 amp was replaced to fix sound.



Tecmo Knight arcade pcb repair

Game booted, but the red & blue color channels were clearly stuck on.  I went hunting for palette RAM and found it on the top board, it’s a slightly unusual type – AAA16K4P-35 with one chip per RGB color.  Swapping in replacements from a Ninja Gaiden parts board restored correct colors, and I could see the video board problems in more detail.

20200606_165823 20200606_165833

One tilemap layer had corruption – the game has 3 tilemap layers and each layer comes from a combination of the Tecmo 3 & 4 custom chips, graphics ROM plus a pair of RAM chips.  One of the RAM chips tested bad straight away, but with that replaced there were still problems.  A logic probe on the ROM showed one of the address lines was floating – but it had continuity back to the Tecmo-4 custom.  Unfortunately this suggested the line had died inside the custom chip.  Replacing this improved things but there was still a fault with tiles being ‘doubled up’.


A logic probe on the RAM chip showed the D0 data line was stuck low, and this traced back to the Tecmo-3 custom – so the doubling was because only even (0,2,4,6,etc) tiles could be selected.  This custom was also replaced with one from the Ninja Gaiden parts board and everything was fixed.

20200606_174202 20200607_162257

20200607_150125 20200607_122146


Taito The New Zealand Story arcade pcb repair

Game didn’t boot and immediately shut down the power supply.  Indeed, a meter confirmed only 2 or 3 ohms of resistance between GND and +5V at the edge connector, so something was shorted on the board.  There’s really no easy way to find a short on a board like this.  Removing all the socketed chips to eliminate them is a good first step as well as looking for physical damage, especially to capacitors that may bridge GND and +5V.


Luckily I found the fault fairly quickly – when I lifted one of the legs of the ZD1 component the short was gone and the board played correctly.  I believe the design of the board is ZD1 provides some overvoltage protection by bleeding the +5V line to GND if required, however in this case it had simply failed and shorted +5V to GND.

_tnzs2 _tnzs3


Sega Afterburner arcade pcb repair

Game ran but sprites were garbage – bad positions and lots of corruption.

_ab1 _ab2

I ran the self test before doing much more – and it came back with bad custom IC30.  This is actually a math coprocessor, and the main CPU uses it for maths to position all the sprites in screen space – so if it fails sprites will be corrupt.

Luckily I had a spare for this chip from a Thunderblade parts board.  Game was perfect after I swapped it in.

_ab4 _ab3 _ab5



Data East Heavy Smash arcade pcb repair

Game didn’t boot – and physical damage was the obvious problem – the PST518A reset controller was missing from the board.  A replacement was taken from a scrap board and the game ran again.


No sound – again some obvious physical damage – the power amp had been ripped from the board.  A brand new MB3730A was bought on Ebay and installed and the game was perfect again.


_heavy3 _heavy2