Asteroids Cabaret Restore

[trm]

If it's a very common chip, or I know beyond doubt it's screwed then I'll just use some fine snips and chop each leg as near to the IC body as possible, remove the IC body and then heat the remains of the pin nd pluck it out using some medical tweezers.

For proper jobs I've got a desolder station (thru-hole and SMD) which is listed in my entry in the "Tech Kit" thread in Tech. ISTR it was about £200-250 ish or so think the price changed a while back.

I've just lent it to my dad for some Namco's he's doing so can give you his objective opinion as I passed him the gear but didn't walk him through the use or setup other than advising him to add fresh solder before he tries to desolder.

If you're in need of some dead boards then LMK. I've got fking thousands

, the vast majority of which are viable repairs so you might get something fun out of the practice.

cheers

tim

 

[Equites]

Dudes

Unfortunately, I cannot get the Asteroids PCB looked at until at least the end of the month, therefore I have decided to try and do some troubleshooting myself. I do understand the difficulties involved in this, but I can follow schemes, have a scope and some electronics knowledge. So, with a bit of luck, guidance and knowledge, I may be able to make some progress.

To date, I have replaced the two 2114 RAMs on the program side with sockets and fresh RAM, the original items were badly rusted.

I also removed and socketed the 74LS42 at L6, isolating pin 1 (DMAG0) in order to try and determine what is causing the watchdog resets.

Anyway, I fired it up, and noticed that the game was now playing blind. All sounds were present and perfect, so at least the sound circuits are fine. However, the game did crash after a couple of minutes, with the repeating firing sounds and the coin counters going crazy as per previously.

So, as P-Man stated probability, there is a problem on the MPU and VSM stages.

I did however notice something, the cab was in TEST mode, how come it is playing blind?? Purity confirmed that the cab should not play at all when in TEST mode.

Hmm, seems like either the TEST switch is faulty or the wiring to the TEST switch is at fault. I removed the TEST switch and using a Multi-Meter, was able to determine that the switch was working fine, however the switch had been wired incorrectly. I'm not sure if an operator had removed it at some point and incorrectly wired it back up, or if it was wrong from factory.

Anyway, I wired it up correctly and replaced the TEST switch back into the cab, now when I fire the cab up in TEST mode, I get the following four tones, HI, HI, LO, LO. Seems I have more RAM issues??
Equites2011-01-13 12:28:20

 

[guddler]

Yep, did out a copy of the manual at it will explicitly tell you which bloop is associated with which ram but you have one or more bad vector rams too which will be enough to cause the DVG to crash.

 

[Purity]

Manual says

1 - D2
2 - E2
3 - M4
4 - R4
5 - N4
6 - P4

So 3 and 4 LO = M4, R4 ram faults?
Purity2011-01-12 13:12:25

 

[guddler]

Damn phone wouldn't let me correct my post!! Yep, assuming it's the RAM and not some of the circuitry associated with the MPU talking to it. Basically socket those RAMs and swap them out first. That may well fix the PCB. If it doesn't then take it from there...

 

[DanP]

Remember that the vector ram is shared between the MPU and DVG. It may be that you have an intermittent failure or just a single address in this ram area that is picked up by the ram test but not during initial running of the MPU. As Gudd says, socket and replace those two reporting bad with some known good 2114's and lets see where you're at then. If you're lucky that will be it and it'll work, if not we'll keep chipping away at it

Dan

Dudes

Â?

Unfortunately, I cannot get the Asteroids PCB looked at until at least the end of the month, therefore I have decided to try and do some troubleshooting myself.  I do understand the difficulties involved in this, but I can follow schemes, have a scope and some electronics knowledge.  So, with a bit of luck, guidance and knowledge, I may be able to make some progress.

Â?

To date, I have replaced the two 2114 RAMs on the program side with sockets and fresh RAM, the original items were badly rusted.

Â?

I also removed and socketed the 74LS42 at L6, isolating pin 1 (DMAG0) in order to try and determine what is causing the watchdog resets.

Â?

Anyway, I fired it up, and noticed that the game was now playing blind.  All sounds were present and perfect, so at least the sound circuits are fine.  However, the game did crash after a couple of minutes, with the repeating firing sounds and the coin counters going crazy as per previously.

Â?

So, as P-Man stated probability, there is a problem on the MPU and VSM stages.

Â?

I did however notice something, the cab was in TEST mode, how come it is playing blind??  Purity confirmed that the cab should not play at all when in TEST mode.

Â?

Hmm, seems like either the TEST switch is faulty or the wiring to the TEST switch is at fault.  I removed the TEST switch and using a Multi-Meter, was able to determine that the switch was working fine, however the switch had been wired incorrectly.  I'm not sure if an operator had removed it at some point and incorrectly wired it back up, or if it was wrong from factory.

Â?

Anyway, I wired it up correctly and replaced the TEST switch back into the cab, now when I fire the cab up in TEST mode, I get the following four tones, HI, HI, LO, LO.  Seems I have more RAM issues??

 

[Equites]

Dudes

So I removed, socketed and replaced fresh 2114 RAM at M4 and R4, replaced the PCB back into the cab and re-tested.

Problem was, I was no longer getting the TEST mode or anything. Seemed the board was no longer responding, apart from the odd beep or hum. Pressing the Reset button on the PCB just gave random results.

I then swapped out the 6502 CPU with a known good CPU, no change.

Hmm, I then re-tested the voltage with the Multi-Meter onto the PCB to measure the +5V and found that the DC voltage was fluctuating wildly from around +4V to +5V. I immediately disconnected the PCB from the edge connector and found the +5V copper trace was very hot. So hot in fact that the heat had lifted the copper trace from the PCB surface.

Damn, so I set about repairing this right away using some strong resin glue;

My attention now turned to the edge connector, this must not have been making good contact creating resistance which in turn made the AR crank up the volts to compensate cooking the +5v trace;

Looking at the +5v and GND edge connector pins, I could see the problem right away. The pins were badly corroded and worn. So bad they were that when I tried to prise one of the pins to add more tension for a cheap bodge it just snapped with ease. These top four pins will definately need to be replaced before I can continue troubleshooting the PCB. Eventually I will replace all the pins;

Does anyone have any spare edge connector pins they could sell me?

Moving on, while I was socketing the RAM at M4 and R4, I make a habit of using a Multi-Meter in Continuity mode to ensure there has been no shorts created during soldering caused by over-spill.

Problem is, while doing this the Multi-Meter showed continuity between pins 16 & 17 on the RAM at M4, infact, since all four RAMs are connected in parallel they were all showing continuity at these points. Im pretty sure this should not happen, so I double checked my soldering on M4 and R4 and it looked fine.

Question is, what is causing this short? Could it be another bad RAM at N4 or P4 (which I have not replaced) or another IC which is causing the short?

Below is an old picture which does not show the new sockets and RAM at M4 and R4, this is just for illustration to the problem;

Equites2011-01-13 13:00:49

 

[DanP]

I take it you didn't do the continutiy check before you added the sockets? I'd say they are the most likely culpret, try desoldering just those pins, you have to be careful with Atari boards, as your pic shows there are also some parts side solder holes, might be that you've just got a little too much solder on one connection so it's forming a bridge. Might be worth removing the new sockets and checking for continuty between those two pins again once you can see they're clean. Other than that you could snip the other RAM but I'd leave that until we've eliminated the new sockets as a possible cause.

Dan

 

[Equites]

Hi Dan

No I did not do the continuity check before I soldered in the socket, wish I had now though. Just for peace of mind I will remove the new socket and re-check the soldering.

 

[Equites]

Dudes,

Last night I carefully removed the new 18-pin RAM socket at M4, also removed all the other Vector RAM (N4 & P4) but I am still getting continuity at pins 16 & 17. The Vector RAM is shorted somewhere but I have not found the cause yet.

I did however find another problem, the Vector EPROM 24-Pin socket has been replaced at some point with a new one, however the soldering job was not so great as I found a broken trace going to pin 23;

 

[guddler]

I'll check the schems a bit later but don't automatically assume that your shorted tracks are really shorted tracks at all. It could be a shorted component. If it's address lines then check the vector rom, the buffer (245 or 244) and any other chip that comes in direct contact with them. If it's the data lines then the same applies but it will be less chips.

Start by removing the vector rom and socket if you think it's suspect and go from there. BUT...

Are you using a desolder station? If not STOP

 

[Equites]

Thanks Guddler

Yes I think you are right, the RAM traces look fine so seems likely to be an IC which has gone short circuit. Checking the schemes for the RAM I found out that Pins 16 & 17 are address lines;

I will therefore check the 74LS244 and 74LS255 IC's. It would be great if you could check the schemes for me on the RAM circuit.

What schemes are you guys using? I downloaded mine from KLOV.

Im pretty sure the Vector EPROM socket is fine apart from the broken trace coming from Pin 23, but I will double check the traces again for shorts or open lines when I get back in tonight.

Yes you are so right, I would not even entertain removing that 24 Pin EPROM socket without a proper de-soldering station. I managed to remove the 18-Pin RAM socket I had installed by cutting the pins down using a dremel, then desoldered the pins individually. It's not ideal I know, and you need a steady hand, but much better than constantly applying heat to a machined socket which are tough to remove.

I do however, have a desoldering station on the way to me and should have it anytime now

 

[guddler]

Ok, cool - I was afraid that the lack of desoldering kit might have been the cause of the problems

Right, so let's back pedal slightly. Even with A7/8 shorted on the RAMs, is the game still running blind with pin 1 of L6 lifted?

[EDIT] As for schematics, I ran off printed A2 (or A1, whatever size they are) copies and flogged them back in about 2003 and I'm still using one of those. It's incredibly tatty these days due to over use mind

guddler2011-01-14 16:07:07

 

[Equites]

Right, so let's back pedal slightly. Even with A7/8 shorted on the RAMs, is the game still running blind with pin 1 of L6 lifted?

To be honest I've not even tried the PCB back in the cab since I encountered the problem with the edge connector, as I was afraid of doing more damage. I have ordered a new edge connector and pins from Bob Roberts but that will take over a week to arrive yet. Is there a bodge (cough cough!) I can use that will let me use the PCB in the meantime without burning out the Sense power traces on the PCB?

I have also yet to resolder the RAM sockets back in place, I was reluctant to do that until I found the short which is tying the two address lines together.

 

[DanP]

Hi, I was going to say, even when you've fixed the edge connector - I run jumper wires from the AR1 test points to the test points on the PCB to avoid just this problem. The harness wiring and connectors can slowly build up resistance over 30 years so adding in something new can work as a preventative measure and maybe even fix some dodgy grounding issues. On my Asteroids Deluxe it hummed like a bastard until I did this. Afterwards it's hummmmmmmm free

Dan

 

[Equites]

Hi, I was going to say, even when you've fixed the edge connector - I run jumper wires from the AR1 test points to the test points on the PCB to avoid just this problem. The harness wiring and connectors can slowly build up resistance over 30 years so adding in something new can work as a preventative measure and maybe even fix some dodgy grounding issues. On my Asteroids Deluxe it hummed like a bastard until I did this. Afterwards it's hummmmmmmm free

Dan

Hi Dan - this sounds interesting, do you mean you ran a +5vdc and GND wire from the AR1 to the +5vdc and GND test points (those loops sticking out of the PCB like the X & Y test points) on the PCB?

What a great idea, this will get me around the edge connector problem for now

 

[trm]

If memory serves me, those hoops on the AR are the same size as one of the spade-style crimp connectors so you can actually do it with proper push-on connectors.

I think I'm going to have to replace the connector on my Star Wars loom when it gets to Springtime and am not really looking forward to it. It's just bloody fiddly work and I'll be doing it in the back of the cockpit so I don't have to pull the whole loom out but needs must.

Glad to see you're giving this a bash dude - very interesting read too. I'll be grabbing a copy of the schems and loading them on my iPad so I can have a read in case I can provide any input, but I think you've got the subject matter expertise already sorted.

tim

 

[Equites]

Made some good progress today and solved the problem of the Vector RAM address lines being tied.

I had another look at the Asteroid schemes and noticed that those two address lines go to the Vector ROM Pins 1 and 23.

Then I remembered that the trace for Pin 23 was damaged, surely the short must be under here?

Anyway, I removed the socket and this is what I found;

In the image above it looks as though the solder pad for pin 1 has lifted, but it has not I assure you. Its just a glob of old dull solder.

Now I need to repair the trace and replace a new socket.

This would explain the problems with the RAM and why it would run fine blind after DMAG0 was disabled by lifting pin 1 on the 74LS42. However, am I right in saying that the MPU can sometimes still access this bank of RAM? If that is the case it could explain why the PCB would crash when running blind??

I have since removed the short (Pins 1 & 23) and the RAM address lines on Pins 16 & 17 on the 2114 RAM are no longer tied

Equites2011-01-15 00:31:53

 

[guddler]

I don't believe the MPU ever reads the vector ram. But i've just got back from the pub so would need to check when sober.

The vector ram is an area where the MPU writes a list of commands. It the signals the DVG to execute them. The DVG then tells the MPU it's done (not via the ram), resets it's position to the start of vector ram. Then the process starts again, ad infinitum.

I don't recall that the MPU ever reads or the DVG ever writes.

Martin.

 

[Equites]

Well

Have made some progress, it has been a bit slow as I have had to do some major reading up, particularly the schemes for Asteroids and play around with my scope.

Turned out the problem was a bad RAM octal buffer DP8304BN at E3, this controlled the MPU RAM and the TEST was reporting a bad RAM at MPU stage even though I knew they were good.

So I swapped the BP8304BN with the one in P2 (Vector RAM buffer) and the TEST then revealed that there was a bad RAM at the Vector side, even though I knew they were good also (I had replaced them previously).

I had made some assumptions that the DP8304BN would be compatible with 74LS245 and had previously replaced both the DP8304BN to eliminate them. This caused the issues of random noises coming from the cab and in constant reset, although the TEST mode worked but constantly repeated itself due to reset after one cycle.

So, 74LS245 is NOT compatible with DP8304BN, at least not the ones I have.

I can get the PCB playing blind with DMAG0 disabled now, re-enabling the DMAG0 still lets the PCB play blind until it tries to access a bank of vector RAM inaccessible due to the bad octal buffer (DP8304BN).

So, just need to wait for some of these DP8304BN's to arrive from Amsterdam now.

Many thanks for the 'jump' lead tips dudes (DanP & Tim), proved invaluable, and as DanP suggested I will be leaving them on.