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%.
Some 13 years after I first simulated the security c-chip in Operation Wolf, an upcoming version of MAME will finally have this chip emulated via the original microcontroller program. The Caps0ff team were able to get the raw data by milling the chip and then using acid to expose the eprom die. The data was then read out using a special adaptor – a work of art! Thanks to Haze also for his work on the microcontroller emulation for the c-chip games.
You can see more of the work by Caps0ff at http://caps0ff.blogspot.com
Certain sounds were missing – explosions and some gunshots. Culprit was quickly found as the 384kHz resonator that drives the two M5205 sample generators was snapped off the board.
Replacements for this item seem quite hard to find new these days, but I took one from a broken Kung Fu Master bootleg and everything worked again.
Board was stuck in a very fast watchdog reset loop, to the point where I thought the reset circuit itself may not be working. The watchdog reset can be disabled by shorting the pad marked JP near the edge connector.
With this done it was clear the CPU was executing just a few cycles then halting. When in halt mode all data and address lines are meant to be released by the CPU, but it seemed D0-D3 were still active. This could have been quite difficult to track down as the data bus connects to many components on the board, but the schematics showed the LS253 @ 19C connected to D0-D3 specifically (most other connections are D0-D7) and indeed a logic probe showed it had active outputs when it should not have.
So what was happening was the CPU would reset and try to read the reset and stack vector from ROM, but ended up getting values with the low four bits corrupted. When the LS253 was replaced, everything worked fine.
Another Track & Field.. no video output, but a logic probe on the CPU seemed to show it was running without the watchdog reset firing. With no video monitor sync is the first thing to check, and although this later revision of the pcb doesn’t match any available schematics sync is easy to find as it still terminates at the 470/100ohm resistors as seen on the regular board.
Tracing back from that point quickly found a Fujitsu LS74 chip @ 11G with dead outputs. Replacing this fixed monitor sync and everything was correct.
An original Irem Air Duel, though when I disassembled it I found an R-Type sticker on the middle board as well. Air Duel was actually released as two different pcbs – the ‘M82′ board as well as the ‘M72′ like R-Type. Although R-Type is considered a great title now, I’m not sure it sold very well when first released, and I suspect Irem were using up unsold R-Type boards when they released the M72 version of Air Duel.
This board came up some garbage when first powered on, then went to a solid black screen. The fact the board did something proved the CPU was running. I knew from the MAME driver this board has software control over blanking the screen so I decided to start there. On the schematics this is the CBLK signal which is combined at the LS32 OR gate at IC63. Logic probe showed the output of this was always low no matter what the inputs were. So bad LS32?
Well, bit of a weird one – the output of the LS32 goes to CN2 (the ribbon cable to the video board) and that pin had continuity to ground with the cable connected. So bad video board? Nope, bad cable – a ‘PC’ style IDE cable was used rather than the Irem original and the pins are actually inverted (so the top row went to the bottom row) and this just happened to ground out that LS32. Of course a whole lot of other pins were connected in the wrong way too – so quite lucky it displayed anything. Original Irem cables were taken from a parts board and the game worked fine.
Two broken boards picked up on KLOV.. I knew they had some missing chips but I only had a quick glance and thought it was just the 68000 and 6502 CPUs plus some eproms. On closer inspection though I found the custom Atari ‘LETA’ chip was missing. That’s also used on more valuable titles like APB and 720 so most likely these boards had been parts scavenged at some point. The LETA chip handles encoding of the steering wheel inputs to the game – but the game should still run without it, so let’s see what was up..
With the CPUs and eproms replaced there was no video output and no CPU activity – in fact the CPU reset signal didn’t seem to be working either. According to the schematics the reset depends on v-blank, which comes from the ‘SOS-2′ custom chip. This chip only has a couple of inputs – the main video clock (14MHz) and an inverted 256H (scanline) signal. The clock was good but the scanline timer stuck. The non-inverted signal actually comes from the SOS-2 as well in a feedback circuit – so bad SOS-2?
A replacement made no difference, but the trick is check what the signals are doing with the chip removed from the board. The outputs should all be floating with nothing driving them (1H to 256H and 1V to 128V) – but 256H was still stuck low. So actually the PAL @ 26R that takes 256H as an input had failed in such a way that the input was stuck low. Replacing this PAL unstuck the timing, and there was now garbage video displayed – progress!
With one bad PAL found I checked the others – and 3 of them became extremely hot extremely quickly. These 3 were replaced and the game sprung into life!
Still no inputs of course but JROK did design a replacement LETA chip which you can read about here http://www.jrok.com/project/leta/index.htm
I probably won’t go that route – adapting the game to use a regular JAMMA joystick sounds more interesting… for a future post.
Unfortunately this had bad main RAM – pretty clear why as it was plugged into the board backwards and absolutely fried. The RAM type (MB87316) is pretty rare – I think only used on Klax and a couple of other Atari games from this era. I’ll shelf this board until some RAM turns up.
This board worked but had a strange magenta outline around the characters. This was a very time consuming repair for what seemed a little fault, it didn’t help I started down the completely wrong path..
What wasn’t the problem
The eproms and color prom all tested good – so it wasn’t a simple case of corrupt data. I’ve talked in many repair logs about pairs of sprite line buffers, which are present on this board as many others. Because the magenta outline was present on all scanlines, this meant the problem had to be after the eproms (where the sprite data is sourced) but before the split into the two line buffers OR after the two line buffers are recombined before reaching the color prom. So this cuts the potential problem chips right down – the eprom data goes to a bunch of 4 LS194 shift registers, which feed into the two sprite RAMs. The data leaving the RAM travels to a LS273 then a LS157 which recombines into a single data stream (which goes to the LS258 which acts as the priority selecter by picking between either a sprite pixel going to the color prom or a tilemap pixel).
However, every single chip tested good, so this theory ended up being a complete waste of time.
What was the problem
The clue came when I forced the color prom to display only tilemap colors or only sprite colors (you can do this by forcing the top address line of the colour PROM either high or low – as per OBJOUTD at pin 14 on the schematics). With the sprite palette forced on the sprites were 100% correct – after checking the palette in MAME I finally understood the fault – the ‘first’ pixel of the sprite was using the tilemap palette, as the magenta only existed in the tilemap palette and was being used instead of the dark brown expected by the sprite.
So why could that be… In the schematics you can see OBJOUTD controls the prom switching between tilemaps and sprites, but the OBJOUT signal controls the data switching. A LS174 makes the OBJOUTD and you can see it’s generated 1 CLK later on from OBJOUT. Why I have no idea.. I didn’t find any problem there so I just patched OBJOUT to drive the prom directly – and this made the magenta outline appear on the right side, rather than left. So instead of the prom palette being a pixel behind it was now a pixel ahead. So it was as if the switch happened ‘half a clock’ out of time which is pretty weird.
I examined what drove the CLK1 and /CLK1 signals which was an LS368. On the original Konami board a custom chip drives the LS368. However, on the bootleg was a weird hack involving two capacitors on the clock input line – one was damaged and removing it made the graphics perfect! Not altogether uncommon to see hacks like this on a bootleg (a capacitor delaying a clock, in this case by ‘half’ or inverted phase) but not easy to find.