Plugging it in gave a screen full of rubbish with fairly regular blinking pixels...
...and despite the often magical results from an unplug/replug of the ribbon cables it stayed that way.
Looking over the board I couldn't see any sign of anything nasty on the CPU board, the video board was equally pristine but someone had resoldered one of the SRAM chip sockets and there was signs that one of the custom chips might have had a touch up on a couple of corner pins but that was about it.
Instead of diving in I wanted to test the $1 CPU board I had picked up, it was a tattier than the CPU board of the complete board set but I had tested all the ROMs, SRAM and CPU on that board before this one arrived and it all checked out, the rotten looking tracks around the OKI sound CPU were also still conducting. So I swapped the boards over and, despite it claiming it had a ROM error, the board booted and ran happily. On a second boot the board decided it didn't have a ROM error so no idea what that was about.
Anyway - this proved that the video board was in perfect working order and I could have called it a day there and then, but the preferable solution was to fix the mint CPU board so it could be paired up with its original and also minty video board.
On boards that give a static screen of rubbish when powered up there are a couple of usual suspects, the first is CPU clock, or in fact a faulty CPU, but that's often far harder to check than the presence of a clock signal. The scope showed that this board had clock in all the right places so I moved on to the next culprit, the SRAM associated with the main CPU.
The SRAM chips are the pair above the ROMs with the yellow stickers on, the edge of the 68000 CPU is just at the bottom of the shot.
Boards that give a screen of rubbish will actually give the exact same screen of rubbish if the CPU or SRAM is physically missing, the effect is the same, i.e. a board that has failed at the very 1st instruction, or a board that isn't even trying to run the 1st instruction if the CPU is bad or missing.
For some reason all the RAM was socketed on these boards which makes things easier or at least a bit quicker, so I removed both TC5563APL chips and put them through my eprom programmer test function. The first chip failed miserably, but the second one was fine. Not having a spare instantly available ( couldn't swap between the $1 and the mint CPU boards as one used fat SRAM chips and the other used the thinner versions) I pinched the TC5563APL that was used as RAM for the Z80 CPU in the sound section. With 2 good SRAM chips for the main CPU the board booted happily.
The sound system was not happy which was not surprising as its RAM was gone, a regular ticking noise was all it produced which is the watchdog circuit constantly reset the Z80 and the YM sound generators to try and get some activity.
Had a dig in my scrap drawer and desoldered a Sony CXK5864 which is an equivalent chip from an old dead board, left the 2 TC5563s together as a pair and gave the sound system its RAM back..
..which restored the sound.
Board fixed!
Or so I thought, I had noticed last night that once in a while some of the sound effects were strange in that they didn't all fit what was going on. It was pretty low level, and didn't always happen, the right effects always seemed to be played but there were sometimes a few additional ones, like an echoing dog howl noise when there wasn't a dog on the screen, or even in the attract mode level. Also perhaps one cycle of the attract mode in ten would have a strange cacophany of noises during the table of contents "eye looking through a hole in some planks" section of the demo. So fired up MAME and ran up the ROMs, the odd noises never happened in the emulated game, and the eye through plank whole screen should be silent, so I had another fault.
The ROMs in the sound section checked out so the next logical step was the addressing for the sound system. If the data bus is faulty all sounds will be mashed, only a fault on the data bus would result in perfect sound effects, just the wrong ones. If there is something flaky on the address bus of the sound section, the Z80 CPU will ask for sample X data by setting the bit pattern on the address lines to correspond with the right sample or noise as dictated by the program it is running. The ROMs will see this pattern plus or minus anything the fault is causing, they respond with the data from a different section of the address space. The CPU doesn't know anything better as it is getting valid data on the data bus so it plays the sound it is given. Faults like this often crash the CPU as as far as the ROMs are concerned they just hold data, its the program the CPU is running that tell the CPU what lives where, and as the program code lives with the sound data its anyones guess if the program itself can run. If the fault has blown a hole in the address area that contains the executable code for the CPU then the instructions will be wrong and will almost certainly crash the CPU. Of course if the fault affects the upper address lines which, if the program code lives lower down in the address space, would only used to address the ROMs areas holding the sound data then you will get odd effects like this.
The fault wasn't that hard to spot either when I went looking for it, the sound CPU had never been soldered in correctly...
...and the pin that was not soldered is A11, fairly high in the A0-A15 address range. Pressing down on the CPU actually chased the fault away entirely which kind of proved the point, but I soldered it in properly...
... and touched up the neighbouring pins too.
The board may well have been making slightly strange noises for its entire career due to this manufacturing fault but in the last hour it hasn't played a single unexplainable sound effect.
It is probably now in better shape than the day it was made.
Tea,toast,Read 