Game ran and played but with corrupt graphics. I was able to swap the top ROM board with a known working one which made no difference which meant the fault was either on the CPU board (which puts the data into VRAM as well as the addressing of the tilemaps), or on the video board (which uses the VRAM output as well as holding the 6 VRAM chips themselves).
In fact this turned out to be a simple repair – one of the VRAM chips was bad with an address bus fault – so it was just putting out data for the wrong address over the top of everything. With new VRAM installed everything was fine.
When I saw the check screen was literally cut down the middle with garbage, I suspected an addressing problem.
First up I checked the connections between the 052109 tilemap custom and the 2 6264 RAM chips. Everything was good there. Next up I checked the addressing from the CPU to the custom – this goes through 2 LS245 latches @ E24 and F24. A logic probe showed A6 was totally dead – it had no continuity back to the CPU. A kynar wire patch was added under the board and everything was perfect again. I couldn’t actually find any scratched traces, so may have been a corroded thru-hole underneath a chip.
No boot with black screen, logic probe showed the 68000 CPU was stuck in halt mode. Piggybacking known good RAM over the TMM2063 chips next to the 68000 CPU allowed it to boot though with bad colors.
Piggybacking known good 6116 compatible RAM over the palette RAM in the middle of the board fixed the colors. These 3 RAM chips were then replaced and game was perfect.
The board was clean and very good condition but booted to a corrupted check screen and would then reset. Comparing the corrupted check screen to MAME suggested one of the palette RAMs was at fault, which certainly would explain the solid red background. With that RAM replaced the game played but unfortunately the corruption was still present along with bad audio.
I had hoped the corruption was just a bad mask ROM for the text layer – but the game’s self test reported all the graphics mask ROMs were correct (both audio ROMs did fail however). Further analysis showed that the corruption seemed to come from the sprite layer – and only on every alternate scanline. The sprite system on this game consists of a pair of custom chips – 053246 and 053247. There are no schematics available so it’s not quite clear how they work but I suspect 053246 is the frontend that parses the sprite list given by the CPU and 053247 is the backend that stores the scanline buffers. As there is no external RAM for scanlines, 053247 probably has internal RAM.
As sprites did appear to work on every other scanline I took a guess that 053247 was the one more likely to have failed and swapped it with one from an untested Overdrive board. Now I had no corruption, but no sprites either. 053246 was swapped and still no sprites – but restoring the original 053247 and keeping the Overdrive 053246 fixed everything – always a danger swapping chips from an untested board as you don’t know if there was also a fault there.
As the self test reported both mask ROMs as bad – and the audio distortion was clearly of the digital variety (harsh square waves as opposed to the ‘analog’ noise a bad amplifier or capacitor may make) I desoldered the 8 meg ROM to test off-board. And it seemed fine. Rather than desolder the other ROM I swapped the 052360 audio custom chip with the one from Overdrive. Audio then worked perfectly and both ROMs passed the self test – so clearly some kind of internal fault in the custom.
Game was absolutely dead with no video output and almost no activity detected with a logic probe. The 68000 CPU was not dead though – instead it was waiting on the ‘DTACK’ signal. DTACK is what the 68000 can use to synchronise writes to external memory where there may be contention with something else on the bus. As the 68000 is frozen you can actually use a logic probe on the data and address lines to detect what address is being written to. In this case it was VRAM – which makes sense as there is contention with the graphics board reading VRAM to draw the screen.
A look at the schematics shows DTACK is driven by, amongst other things, the N1H and 2H (horizontal clock) signals and these were dead. Those signals come from the 05292 custom chip on the video board and unfortunately it was completely dead. This chip is really the heart of the board as provides all timing so without it pretty much no element can run. A 05292 was substituted from a Salamander, and Lifeforce ran which proved the 05292 was at fault.
The Lifeforce had a couple of glitched inputs, some were down to a previous repair where one of the optocouplers had been replaced – bad solder joints on the socket. Player 1 left however remained stuck on and it seemed one channel of another optocoupler had failed. As I didn’t have any spare, I used a trick – this hardware is setup for 3 buttons per player, but the software only uses two. So I cut the trace for player 1 left to the failed optocoupler and patched it to the unused third button input, then patched the optocoupler output back to where it should be. Worked perfectly and all inputs good again.
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!