Sega Turbo is quite a complex pcb, certainly very complex for 1981, and also a bit of pain to repair. The video output isn’t compatible with my usual Sony PVM test monitor (hence the red only display), but also it requires -12V as well as +12V which not all modern PSUs supply. The problem with this board is stretched sprites – in fact all sprites are stretched to their maximum value.
The way the sprite scaling works is quite interesting – unlike the digital processing in most arcade games, the scaling is effectively analog. The clock signal used to read the sprite data can be sped up or slowed down with respect to the scanline pixel clock. So if the sprite clock is slower then the sprite will effectively be scaled bigger across the scanline as the sprite pixels ‘smear’ across multiple scanline pixels.
The current scale value is held in the LS373 at IC1 on the video board – the drives a digital to analog convertor – UPC624D which then drives a UPC159. Notice how the two analog components require -12V – without that the sprite clock will not run at all and there will be no sprites on screen. If the LS373 fails with all outputs high the board will display the maximum scale, likewise if the UPC624D fails with high output you get the same effect as both cases lead to the UPC159 getting maximum voltage. On this board the UPC624D had failed and was replaced to fix the problem.
A pair of Galaga boards, both of which displayed garbage and continually reset. First thing to check is the usual basics – do the CPUs have a clock signal, is the reset line working correctly, is the data on the ROMs valid? Between both boards 3 failed CPUs and 4 bad eproms were found. With them replaced problems such as random resets and missing sounds remained – but after a lot of debugging it all came down to dirty sockets or corroded chip legs. After a clean-up both boards were stable.
One fault remained on one of the boards – for all sprites only the blue channel was displayed – unfortunately this turned out to be a failure of the sprite color PROM at location 1C on the video board. A replacement was pulled from a bootleg Gallag in order to fix the original board.
Game did not boot and just displayed a solid color screen. The Z80 cpu, located on the lowest board of the 4 board set didn’t show any activity with a logic probe. It hadn’t failed though – instead the WAIT line was being held which prevented the CPU from doing anything. There are actually 4 different potential sources for WAIT on these boards, so any of them could have failed as well as the OR gate that combines them. Testing with a logic probe revealed a bad LS74 which was replaced and the game could now boot.
Quite obvious though that some graphics were wrong. Frontline and other Taito SJ games are a little bit unusual – instead of the graphics hardware directly accessing the graphics ROMs, the graphics hardware draws out of RAM. So the CPU has a banked port into the graphics ROMs which it copies to video RAM as needed.
So in this case the problem wasn’t actually on the video board, but in how the CPU was reading the ROMs. The schematics show a bunch of 40193 chips that control the address lines for the graphics ROMs. One of these had failed – a logic probe showed dead outputs. A replacement was fitted and the game was 100%.