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).