Asteroids PCB fault

[guddler]

OK, so I'm putting this here primarily to demonstrate how different repairing PCBs can be when you have a Fluke Troubleshooter (9010 or 9100 in this case).

Symptom: Board resets constantly in play mode with fast flashing coin lamps. In test mode it displays 3 FF & 5 FF (or maybe some other numbers, I don't remember).

First thing I did as routine really was to replace the ROM sockets as they're crap, and also I noticed that while it was still working, the crystal was broken internally and physically flopping about all over the place so I fitted a new low profile one which should never get snapped off again. I knew the crystal would make no difference to the problem, and I felt it unlikely the sockets would but I did it anyway.

So. This is where things differ hugely if you have a Fluke. If you don't, you now need to start prodding about with a logic probe to see what you can spot in terms of stuck bits, dead bits and so on, all the while not really sure what's going on with the PCB. If this thing is constantly watchdogging for instance, are you 100% sure that the pulsing activity you're seeing on inputs is for sure not a result of the very tightly looping reset on the board? No, thought not!

So, we plug the Fluke in. I've got some scripts that I wrote years ago that I run but they essentially just automate what you can do on the front panel directly. I don't do much fancy with the 9100. The main difference at this point with the 9100 over the 9010 is that the 9010 can test against a bit mask when doing tests, the 9010 cannot. This means that with a 9010 2114 RAMs need to be tested in pairs as they're 4 bit RAMs. With a 9100 you can do them individually.

Anyway, so I ran the RAM tests and as expected all was well there. I ran the ROM tests and as expected, all was NOT well here. I would get:

• Vector ROM: Pass
• Program ROM 1: Pass
• Program ROM 2: Fail - all bits stuck high
• Program ROM 3: Pass

I don't recall the exact ROM locations and TBH, it's not relevant. Before jumping to conclusions, I swapped ROMs 2 & three and then got:

• Vector ROM: Pass
• Program ROM 1: Pass
• Program ROM 2: Fail - incorrect signature
• Program ROM 3: Fail - all bits stuck high

OK, this sounds like a simple bad ROM. It sounds like the problem is moving with the ROM (after swapping the ROMs, ROM 2 would be expected to fail as it would no longer produce the expected ROM signature.

Before I checked the ROMs however, I recalled that ROMs had already been swapped in from another board so it couldn't be the ROMs themselves. I swapped them over again just to remind myself and be sure. I also did a ROM test with no ROMs at all and got a similar error message so it didn't make sense for it to be a ROM at fault.

So, really, before we get as far as bad tracks or crap like that, there are only a couple of things this could be. From most likely to least likely:

• ROM fault - can't be, we've proved that.
• Addressing decoding fault - could be
• Buffer fault - can't be, the data goes through the same buffers as the RAM and those tests pass.

So, as we can see, this is looking mostly like an address decoding fault. Another fault could be address buffers, but I've not listed that for the same reason as it can't be the data lines. The lower address lines are buffered and if those buffer chips weren't working then RAM tests wouldn't pass either.

That then leaves us with the address decoding. The upper address lines on boards don't tend to be buffered. On Asteroids they go to one half of a 74LS139 at L3 (position may vary depending on PCB revision) and so quite frankly, this is immediately our suspect.

And this is where I always initially cheat. Some ICs, and particularly ones with simple two-state pins (as opposed to tri-state outputs) can be "piggy-backed" onto the suspect chips. It's by no means a scientific test, and indeed, if the IC you suspect has a short, it could damage the good IC, but I always think it's worth a try. If you can categorically go "fixed", "not fixed", "fixed", "not fixed" as you add and remove the good IC on top of the bad one then it's a pretty safe bet that's your culprit. If you get inconclusive results then you have no choice but to go into things properly.

In my case, I piggy-backed a good LS139 @ L3 and guess what? Game fixed. And this was 100% repeatable so I cut the old chip out and soldered a new one in and the board was fixed.

Apart from an issue in the analog output section, but then it was dinner time

So as you can see, a VERY, very difference repair experience due in no small part to the test kit available...

Maybe people can see now why I find it so hard to speculate as to what may or may not be wrong with peoples boards unless they're on the bench in front of me.

Also note, it has taken me 2 or 3 times as long to write this as it did to find and fix the fault - which is why I rarely write repair logs any more

 

[guddler]

OK - onto the analogue "fault"...

This was nigh on impossible to get a picture of but I have tried...

It doesn't show it very well as it was difficult getting the phone to focus properly in the first place and so the picture kind of just looks like it's out of focus so you'll just have to trust me when I say that all of the lines looked like they were doubled, or another way to put it, like they were 3D with a second more faint / de-focussed line right next to it.

Anyway, this is an early revision board, an 02 revision. Personally I've not seen one before but on the Asteroids schematics for the later revisions there's a bunch of stuff that's always shaded to show that it's optional. Notably a lot of it is in the output section and I think it's related to the Sample & Hold circuitry. I was a bit suspicious about this so I socketed everything in that area of the board and swapped it all about to see if anything changed. The DACs, the TL082's, the 4016's. And I re-capped that area and all the voltages supplying the analogue section and everything, but nothing I did made any difference and my scope didn't really show any significant AC noise or difference compared to a working board so I was beginning to draw a blank.

Here is a picture of that area of the board showing that compared to a later revision board, literally half of it is just not there. It's not that it's screened on the board and not populated, it's just not there at all! Must nicer for troubleshooting, far less to understand

So anyway, I went back up the shed to have another look this afternoon with the specific intention to try this on a real vector monitor just to satisfy myself that it really was a fault. Because there was such a difference in board revision, specifically in the area I believed the problem lay, I wanted to make sure I wasn't chasing ghosts.

And here we are: sure enough, chasing ghosts. There is no problem when used on a real vector monitor. Seems you learn something new even after all these years of dealing with Asteroids faults! What can I say? At least the PCB has now all been re-capped and the analog section is now nicely socketed!!

 

[Alpha1]

Absolutely lovely write up and repair work dude

 

[RGP]

f***** A!!!!!!!steroids!

I need access to one of these Fluke's for my Galaga board, probably find the fault in minutes with it.

 

[guddler]

You're welcome to pop round for a cuppa. I fear it's a bit of a long way though

Tim's a lot closer...

The problem with Galaga is the multiple CPUs and how they interact with each other. It's just a pain in the arse, however yes, a Fluke would allow you to intelligently troubleshoot each CPU's space individually, then when you know they are all able to read and write what they should, then you can tackle whether they can talk to each other. By then I imagine you'd have found the fault.

I would offer to do it for you but I'm limited at the moment by the temperature. I had another Asteroids to look at and Oll's Mazer Blazer really but it was too damn cold up there so I came back to the house. I need to spend some evenings up there if I can to try and get on top of what's outstanding. I have my own BZ still needs a PCB sorting for it.

guddler2014-01-06 00:25:46

 

[guddler]

Oh, incidentally, I'm not knocking or intending to debunk anyone that troubleshoots boards with simple tools like logic probe or scope alone incidentally. In fact, quite the opposite, I salute anyone that does that and I'm not sure that I could any more!

I understand that a Fluke will set you back an absolute fortune these days and if you only do the odd repair then it's simply not worth the expense. I bought my first (9010) a long time ago (2001 maybe?) and upgraded to a 9100 in 2008. But then I was repairing a large amount of boards at the time.

 

[Equites]

Symptoms

The PCB ran fine, but absolute no output in TEST and the game/attract showed only faint dots dancing around the screen.

Solution

Found that the decoder (LS42) at E8 had pin 3 stuck HI (should have been pulsing along nicely), replaced with a fresh decoder and now PCB is 100%.

 

[Zektor]

Nice write up! I would have stuck a comparator on that chip...I don't have a fluke

What was up with the scope image ? Poor grounding of the probes ?

 

[Equites]

REVISION 2 PCB



Symptoms
PCB is dead and watchdog is barking, PL1 & PL2 flashing rapidly in GAME mode.  No TEST mode.

Solution

Checked ROMs, F1 and N/P3 (Vector ROM) were bad, fresh ROMs burned and replaced.  Still no GAME or TEST mode.

Found that all six 2114 RAMs were bad, yes all six.  Replaced, we now have both GAME and TEST mode.

However, we have no sound except for explosions, the 'thump thump' sound is a click/pop instead.  Checked the +15v regulator at VR4 which checked out good.  Checked the 74LS259 at M10 which latches most of the sounds, output pins were floating.  Fresh 74LS259 inserted at M10, we now have all the sounds but still no 'thump thump' heartbeat sound.

Found the 0.22uf Mylar 100v cap at C33 was missing, replaced and 'thump thump' sound returns.

Game plays great except for the vectors look a bit grainy, also, when objects move they sort of fold, as if the object has gone over a crease/fold vertically.

Checked all the output op-amps (TL81s & TL82s) and they looked good, also checked the Bi-Lat switches in the output section (4016s) and they were also good.

My attention turned to the DACs, I swapped the two DACs over and the problem remained, except the crease/fold effect is now horizontal.

Replaced the failing DAC, PCB now 100%.

Equites2014-06-05 16:20:36

 

[tb lilley]

Show off.

 

[Equites]

REVISION 2 PCB



Symptoms
PCB is dead and watchdog is barking, PL1 & PL2 lit solid. No TEST mode.

Solution

Found a failed decoder (74LS139) at position E4 - Output Pin 11 was stuck HI. Replaced and PCB is 100% working.

REVISION 2 PCB

Symptoms
The Thrust sound only lasts a split second and then stops. Explosion sounds have been replaced with tone sounds.

Solution

Found a failed shift register (74LS164) at position P9 - Output Pins 12 & 13 were stuck LO. Replaced and PCB sounds are all 100% working.

[/b]Equites2014-06-18 14:43:45

 

[Alpha1]

My God how many Asteroids PCBs do you have

 

[smarty]

Nad, can I ask what were your tools of choice and procedure was for finding these faults? Logic probe ,scope, fluke etc.

Cheers, Mart.

 

[guddler]

You ought to be able to find both with a simple logic probe in this case. The Fluke would make at least the LS139 easier by being able to repeatedly drive that chip in a specific way. You should be able to do the same with the sound fault as well.

Sound faults don't always take that much as they're pretty straight forward on Asteroids so it's often enough just to look at the schematics and replace the obvious part. Becomes a pain in the arse when capacitors or other analog parts are involved mind

 

[Equites]

Nad, can I ask what were your tools of choice and procedure was for finding these faults? Logic probe ,scope, fluke etc.

Cheers, Mart.

Martin - It was pretty much the way Gud described it really. In this instance, all I used was a logic probe. I like to start with the logic probe to check CPU state and activity. Really, I should use the Scope alot more but it is much more hassle to setup, and much more bulkier. That is pure laziness on my part, and I have been caught out before in the past because of it.

The Logic Probe is great for looking for floating lines/pins, and for quickly checking states of Inputs/Outputs. However, it is useless really for checking RAM. This is where a Scope shows its worth.

A Logic Comparitor is very useful for checking Tri-State ICs.

An EPROM Reader/Writer is essential to verify ROMs/PROMs are good.

I had a good idea of where the problem was for the PCB that was dead, because disabling DMAG0 (lifting pin 1 on the LS42 at location L6) made no difference, so to me that implied the problem was at least in the MPU (Program) section in the first instance. If the VSM (Vector State Machine) section was stopping the PCB from running, it would have ran blind when I disabled DMAG0.

This is where the schematics come in handy, especially Atari ones, which are rich in information, and circuits are broken down to specific area's.

The sound section, I know from experience that if you have Thrust and Explosion sounds, then the noise generator circuit is working. In this case I had all but those, so I knew exactly where to look in the schematics, and found the problem in the first place I looked. The sound circuit on Asteroids really is very easy to follow and understand.

The Fluke is a great peice of kit, but it is not really a tool to pinpoint exactly where problems are. I think most people assume it is some kind of artificial intelligence that will tell you exactly which IC is bad. It does not work like that, most times anyway.

What the Fluke can be is a time saver, it can help to narrow down where the problem may be. The best way I can describe it is like a torch when working on a car engine. It's not essential, but can help speed things up and help find problems quicker. However, it won't replace that spanner (i.e. Logic Probe/Scope), you still need that.

Having a working boardset to compare against can help a great deal to remove any doubt.

Equites2014-06-19 12:16:44

 

[Equites]

Symptoms

I thought I would document this since it was a more interesting one and I've not seen anything documented before which was similar.

Asteroids PCB was playing perfectly, Test mode 100%, all sounds are present.

However, there is a constant high pitched whining noise coming from the speaker (already confirmed it was not the wife). It seemed to be getting progressively louder as time went on (not too dissimilar to wife).

These kinds of problems can be a nightmare to locate, as the noise in the circuit could be coming from anywhere. Asteroids has a analogue sound circuit where individual sounds are eventually mixed and fed into a op-amp (LM324) in the final stage.

I had already previously proven that the op-amp was fine, and that the whining noise was being fed into the op-amp.

Solution

I started by looking at the schemes, and noticed that the individual sounds are fed into the LM324 op-amp at P11;

I decided to isolate each sound circuit until the whining noise stopped, so started to lift one leg of each resistor starting with R83 in the illustration above.

Eventually I got down to R78 and the whining noise had gone. So, I knew the noise was coming from the Extra Life Sound circuit.

Again, I looked at the schemes, and noticed that like all the other sounds, the Extra Life Sound is latched though a 74LS259 at M11, and generated from a 4016 Bi-Lat switch at R11. Luckily, the Extra Life Sound circuit is the simplest on the the PCB.

The problem had to be coming from the Bi-Lat at R11 (There was nothing else in the circuit). So I removed, socketed and inserted a fresh Bi-Lat.

Problem solved.

Equites2015-01-16 11:35:20

 

[Stevros]

Great logs here thanks guys

 

[tb lilley]

Nice write up Nad. Even a mong like me followed that.

 

[RGP]

Love repair log threads, well done Nad.

Like the anecdotal comparison to the wife ......

 

[Nes4life]

Symptom



Test grid looks like a chain fence; although the diagonal lines are present there are very tiny vertical squiggles. In play the game appears to have quite large horizontal bands of space sort of like an 'every other line' scenario.




Solution




Initially I thought it was a Y-axis counter but actually turned out to be the Y-axis DAC

Nes4life2017-07-26 08:28:24