Taito Sky Shark arcade pcb repair

No video output from this Sky Shark, aka Flying Shark but the main CPU and RAM did show activity via logic probe.  There are no schematics available so I traced out where the RGB lines on the jamma edge connector go.

And they go to the resistor network at the right side of the board, so the digital palette is converted to analog video signal as expected.  The resistor network is fed by the two LS273 latches in the N row and I presume those two latches are clocked by the pixel clock to output each pixel as supplied by the palette RAM.  No clock was present though – so I traced the clock signal back to the LS08 on the M row.  This seems to be how the game handles the horizontal and vertical blanking – so the pixel output is turned off when needed.

The MAME source indicates the CPU can also turn the screen on & off – and it’s this signal that also goes to the LS08 – by (temporarily) bridging the input pins I forced the screen on – and got a screen full of garbage!

So that’s actually a good thing – confirmation the pixel clock is working, palette RAM works, tilemap RAM works, etc, and likely confirmation the CPU program was not running long enough to turn on the screen.

Piggybacking the main CPU RAM with known good RAM had no effect, and the program ROM’s seemed fine, so I used the MAME debugger to trace the program a bit – and it seems the program is very delicate – any RAM or DSP error leads to a crash rather than any on-screen indication (so although the game reports ROM:  GOOD  RAM:  GOOD on successful bootup – it will generally never report something bad – just crash!).

Now after all that, I examined the board in more detail and found 3 gouged traces on the underside – when repaired the game worked 100%.  So I went down the wrong path for a while but fixed in the end.