Defender Troubleshooting Problems

[dais3]

Hi there
I'm new to these forums, my name is Dave and I'm the proud owner of an original Williams Defender red label. I've had the machine for a year or so, and it worked lovely, but has now decided to stop working.
Yesterday I broke out the scope to start taking a good look at it, but after a whole day with the manuals and a scope I'm somewhat stuck and desperately in need of some advice.
Here's what I've done so far.
On start the machine goes into the rug pattern and stays there. The pattern refreshes every 3/4 seconds, but never clears and goes into the tests.
I rebuilt the original linear PS when I got the machine. I've rechecked all the voltages: 5.13, -5.08, 12.24 regulated and +14.5 and -14.5 unregulated. I also replaced the 4116 RAM with 4164 when I got the board as well. Also it has a lithium CMOS RAM battery and no acid damage.
With the scope out I can see the 12MHz clock along with the 6 and 4 as they should be. The E and Q clocks to the MPU look good.
Now the fun starts. Looking at the watchdog circuit, the NOT RESET goes low every 3/4 seconds. My assumption is that this ties up with the refresh of the rug pattern I see on the monitor. I cut the pad to disable the watchdog circuit, which then held the NOT RESET high. With this the rug pattern no longer refreshes, but it still stays in the rug pattern indefinitely.
For good measure I swapped out all the RAM to the original 4116 chips with no change. Also swapped the MPU as I had a spare lying aound - again, no change.
I have checked the ROM board, pulled all the ROMS, sanded the legs and reseated. No change. Check continuity on the ribbon cable to the CPU board - that all checks out.
I'm really wondering where to go next. Any suggestions/pointers would be most welcome.

 

[andyman]

Rug pattern staying on usually indicates bad voltages, have you checked sockets on the ram, again a usual culprit of a non booting Defender. Or decoder issues, remove & reseat the two decoder proms

Andy.

 

[DanP]

I take it there are no flashing red lights on the rom board? With williams games of this era it's worth eliminating all the connectors and header pins for continuity and bad solder joints (for the latter). I've had issues like yours and fixed them by replacing the connector cable between the Rom board and the CPU board (just using a modern ide cable). Second thing to check is that each board is getting the right power voltages (measured at each board not at the psu). Are you able to verify the roms individually?

If all that checks out you're into Fluke territory to try and work out what's going on in the address space.

Cheers,

Dan

 

[dais3]

Thanks for the replies.
I get no leds on the ROM board. They all go on when I pushe the reset switch, then they all go off and stay off.
Voltages checked on the ROM VCCs at 5.08V and on the CPU board at exactly 5v and as 4.94V on the RAM chips themselves. These all look within tolerance I think. I pulled the two decoder ROMS, gave the leads a sand and replaced. Same behaviour.
Thanks
Dave

 

[gt6freak]

Hi,
I've no specific experience of these machines, but it sounds to me that everything is mostly working - CPU / display RAM must be operating to get the rug pattern. Perhaps the CPU is getting stuck in an endless loop, causing the watchdog timer to reset it (you could verify by checking the CPU read strobe on a scope and seeing if there's a repeating pattern).

I'd agree with DanP - verify the ROMs individually, - i.e. check that they have the correct code in them. EPROMs are only guaranteed by the manufacturers to hold data for about 10 years before they start dropping bits (although in practice they're usually ok for 20-30 years, but we're way past that in any case!).

Also, 4116s are unreliable and need 3 supplies (I know that from fixing ZX Spectrums!) but if you've already replaced those with 4164s that's less likely to be the cause. Still, check for any RAMs which are hotter than the others. You can also snip the output leg on those RAMs (use pointy ended cutters, near the plastic package) and temporarily piggy-back a known good one over the top, using the springeyness of the legs to make contact, and so that output pin of the good RAM drives the old leg sticking out of the board. You can try each one at a time, resoldering the output leg of the one you've just tried before moving onto the next. Test the ROMs first before opting for surgery though.

Hope that helps,
Mark

 

[Ravage]

A non-stop rugging pcb can also be an indication that the ribbon between rom and main pcb is iffy too...

Additionaly worth swapping around 4116s in the first row like 111 or 121 or 131 as sometimes the machine cant access the first ram to have ram to report the error I'm told. The best way to check rams is to use a logic probe: every leg should give the same back (hig/low or plusing). A ram doing something oither that is either a) the chip, b) the socket itself as theyre often wrecked or c) something else but 90% of the times its a or b!

 

[dais3]

So I'm still stumped by this. Replaced the ribbon cable from the ROM board. Same behaviour. Swapped all the RAM out and tested it on my Stargate board, no problem running Stargate. Really not sure where to go next... (at least I got Stargate to play with while I sort this

 

[dais3]

Oh, I also swapped out the supply to my spare one. No difference... Hohum...