Good condition MV2F but graphics were corrupt. As often happens with NeoGeo’s acid from the battery had leaked and destroyed a couple of traces. These were patched with Kynar wire and a fresh battery installed and everything fine again.
Board 100% dead – volt-meter on various TTL chips showed only 1V instead of 5V. Edge connector was very dirty/corroded – after cleaning up with some 2000 grit sandpaper, all the TTL had a solid 4.98V but the board still remained totally dead. The crystal was found to be quite corroded – in fact the legs literally broke off when I tried to remove it. A replacement was fitted as was a replacement for the LS368 – bizarrely corroded despite other chips near it being fine. The socket was also completely trashed with rust.
With those fixes in place video output worked – the game showed random garbage but the CPU was obviously not running. A tip for Ms Pac is that you can remove the CPU daughterboard and put in a Z80 and rom set from a regular Pacman. After cleaning up the ROM sockets the Ms Pac board worked using the Z80 from a working Pac. This meant the next problem was localised to the daughterboard. Cleaning the sockets and ROM legs didn’t help – in fact the Z80 on the daughterboard itself was dead. With a fresh one installed the game worked.
However, audio only worked for about 10 seconds at a time then faded out to silence. I assumed this was just bad capacitors and recapped the entire audio section – which didn’t help at all… So I started at the speaker output in the schematics and worked backwards – all sounds go through the 4066 @ 1N and the LS273 @ 2M. The clock signal to the LS273 was dead so no sound data could get through. That clock is driven by the prom at 3M and it this clearly had some kind of internal failure. With a probe on the prom output pin I could see the voltage drain away as the sound died. Substituting 3M from a working Pacman confirmed the failure as everything worked 100%.
The game booted to a pink screen with some garbage sprites visible. With this board and other Data East boards of the same era (Captain America, Locked n Loaded, etc) that’s a sign the CPU is running at least some of the program correctly. That’s because the CPU must enable the graphics output manually. So if that CPU hadn’t been running this board would just have booted to a solid black screen.
With the program ROM ok, next likely problem is the RAM, though it’s usually quite reliable on these boards. I had another idea the problem might be the security/input IC, marked 104. I used a custom build of MAME to fake a bad 104 chip, and behavior matched the real board – the program ran far enough to enable graphics, then just looped waiting for the security IC to respond.
The 104 chip is used on a handful of other Data East titles including Caveman Ninja, Pocket Gal Deluxe, Wizard Fire, Rohga, etc. I took a chance and desoldered a 104 from a Caveman Ninja, and success – the game booted!
Some tilemaps had bad colors – however this was easy to find – lifted pins on one of the ’56′ tilemap customs. After a reflow all the graphics were correct.
Still no sound – an obvious problem was corrosion on the program ROM and socket. A replacement ROM didn’t bring back sound but a logic probe now did show the ROM data lines appeared to be pulsing correctly, so the CPU was hopefully running. The main amplifier is usually the first thing to check for sound problems, and as I didn’t hear any background hum at all I suspected it was dead. This amplifier is actually quite easy to obtain new as it was used in many televisions, so a brand new one was ordered and fit and sound worked.
I’d previously replaced all sockets on this PCB and cleaned the ROM legs as both can tend to go bad on Asteroids boards. Now a year or two later, it was making a loud humming sound and constantly resetting. Test mode did run though albeit with bad vectors. However it displayed well enough to print ’2N’ on screen. Indeed the IC at 2N is one of the vector table ROMs and it did seem to be bad as a replacement eprom was fitted and gameplay worked again.
Asteroids like other early games, has separate circuits for each sound effect – the fact they were all out and only a hum could be heard suggested it would be the summing amplifier that combines all the individual sounds. The LM324 at location P11 was replaced and everything was good again (a compatible ‘GM324′ from a DragonNinja bootleg was used as I didn’t have any LM324′s to hand).
At first glance this fault appears to be a variant on the common ‘failed sprite linebuffer’ problem that often crops up in arcade pcbs where every 2nd line is missing. In this case though every second line is drawing incorrect sprites – and all up against the left side of the screen. Because there is actual sprite data on every scanline, the line buffer circuits themselves must be working – it’s what is being put into one of them that is the fault.
As the sprite tile is wrong the address lines of the sprite ROMs are the first place to start (as the address lines control what tile is output to the line buffers). The address lines all trace back to the 86S105 custom chip and unfortunately it’s where this repair ends. This chip completely integrates the frontend of the sprite processing and seems to have failed internally. The chip itself is almost certainly based on the design of earlier Capcom sprite generators like Ghosts n Goblins. That game has RAM for the sprite list, then two more RAM chips for an attribute buffer that alternate every scanline. Most likely one RAM or supporting logic has failed.
Interestingly some Googling revealed a picture of a Black Tiger prototype where the custom chip was replaced with regular TTL – and although the picture is low res the 3 6116 RAM chips can clearly be seen.
The only fix is to replace this custom chip, which is also used on 1943 and Buster Bros/Pang.
Update, some weeks later..
Well, thanks to JoeyBagODonuts on KLOV who donated a broken Super Pang this board is working perfectly again. The 86S105 custom was swapped and everything worked!
Certain graphics had corruption – usually solid lines through certain sprites or frames of animation. As the issue was specific to certain frames I was fairly sure it would be a ROM problem, as a RAM or TTL problem would most likely affect all graphics. ROMs H2 and H3 hold the sprites and although H2 was in perfect condition like the rest of the board, it contained some corrupt data. A replacement was fitted an everything was fine (a 27c32 was used as I didn’t have any 2716′s – this is fine if you burn the ROM data to both the upper and lower half).
Another Ghostbusters, and like the previous repair no video sync or output although a logic probe seemed to show the CPU was running. I expected to find a bad 74LS chip or a gouged trace on the bottom video board, but I pretty quickly found the custom chip that is meant to produce monitor sync was completely dead. The DRL40 custom takes some timing signals, has a reset line and takes a 12MHz and 6MHz clock. In return it is meant to produce monitor sync and sprites. Even though all the inputs appeared correct absolutely nothing was appearing on the output lines. Manually grounding the reset line didn’t do much either.
When I looked at the board in sunlight though a tiny crack was obvious in this chip – so it had certainly failed and probably made quite a loud pop when it did so. The chip was removed and a replacement taken from a Gondomania pcb soldered in – everything worked again.
Game booted to garbage on screen. Logic probe showed the CPU was continually being watchdog reset. ROM & RAM are usually the next things to check and was quickly clear the enable pin on the RAM @ G2 was floating/disconnected. This traced back to a Fujitsu LS139 at H13. With that replaced everything worked again.
Game would show an initial flash of garbage on 1st power up then get stuck on a black screen and continually watchdog reset. The watchdog can be disabled by shorting the jumper next to the test switch and with this done it was clear the CPU was running fine. In fact it seemed to intentionally be clearing the screen to black and then just sitting in a loop somewhere in code. A logic probe on the IPL (IRQ) pins showed it was responding to interrupts correctly which pretty much also proved the main RAM was working fine (if the RAM was bad then garbage would have been pulled from the stack at the end of the IRQ which would have caused a crash/bus error).
The game uses a selection of GAL chips mainly for memory addressing – I burned replacements for each one with no difference. The ROMs tested fine of course and all address & data lines had continuity from CPU to ROM to RAM (the latter via a pair of LS245s).
The culprit turned out to be the 2816 parallel eeprom used to store the game settings – when tested it showed a just a couple of bad bits that would randomly change on each read – if it had fully failed it would have been an obvious fault. When replaced the game worked fine, so whatever bad pattern this eeprom gave out managed to confuse the program into getting stuck.
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.